Some of us may have already heard the new word combination which had spread over the Internet society - Certificate Transparency. This process and, which is more important, the novelty of this concept itself have been recently announced by Google Inc. So, what certificate transparency actually is? Let us have a look.
As originally defined and planned by Netscape and others in the mid-1990s, certificate issuance process implies that a Certificate Authority (CA) should generate and present the certificate for the certificate requester (domain owner, server administrator) for review and approval, prior to the actual SSL’s issuance. Once issued, the Certificate Authority publishes the certificate in an independent repository which will prove that the requester has been aware of the certificate’s issuance. That independent repository allows public key (which is an essential part of SSL certificate) verification and validity check prior to establishing and negotiating a secure session with the server. In a way, a public key can be alternatively validated besides for getting it from the server solely during session negotiation. Certificate Transparency project brings up a new way of making certificate’s issuance process publicly available, open and, no matter how tautological it sounds, transparent.
How is the certificate transparency achieved?
Certificate transparency (further CT) is achieved by having Certificate Authorities post certificates to publicly accessible Qualified CT logs. There are four main participants in the CT:
Firstly, a Certificate Authority creates so called pre-certificate which contains main information that will be reflected in the future certificate and sends it to the trusted Log server.
In its turn, Log server accepts this information and replies with a ‘signed certificate timestamp (SCT)’ which is, by nature, a ‘promise’ to add the certificate to the log within a certain period of time. This time frame, known as Maximum Merge Delay (MMD), sets the reasonable period when the certificate is added to the Log server. One might question oneself if the MMD value can actually delay or postpone the certificate’s issuance. MMD has influence neither on SSL’s issuance nor on certificate’s usage. The largest MMD timeframe is 24 hrs, meaning that all newly issued certificates will be available in log maximum within 24 hrs once SCT is generated.
SCT goes ‘hand in hand’ with the SSL certificate throughout its life cycle, until the expiration or revocation.
SCT is accepted by the Certificate Authority and integrated either in the body of the certificate or presented by other means. SCT presence and availability in SSL Certificate itself serves as a signal that the certificate has been published for review. There are three general methods for CT to deliver SCT with the certificates: x509v3 extension (which actually requires no additional actions from server operator), TLS extension (which is to be used by site operator with type signed_certificate_timestamp for SCT delivering to the client during TLS Handshake) and OCSP Stapling.
More details on these methods can be seen here, but the main idea is that Signed Certificate Timestamp is presented along with the certificate itself during session negotiation.
Pros and ….Pros!
The main and the very first advantage which comes to our mind is trust. Having company details published and open for viewing builds a way better image while doing online business. This point is beneficial not only for CAs, domain owners and server operators, but also for a great number of end users. Google is currently running a Certificate Transparency log which is filled in with the certificates retrieved from the web, and active work is performed on monitoring and auditing software which can be reviewed here. The development of a new Google Chrome version is currently going on. At some point, it will be updated to show a warning message prior to establishing a connection to a website without a verified SCT. After adoption of certificate transparency by Certificate Authorities and browsers increases, Chrome is planned to be modified again, so that no connection to a web site without a valid SCT along with the certificate is performed (but this setting can be changed by a Chrome user).
Another advantage concerns Certificate Authorities’ business model: SSL certificates are issued just the way they were, except for one extra step: first, the certificate is sent to several Log servers to receive and include a timestamp to the SSL. Domain owners or server administrators will not need to adjust to new SSL-performance procedure. TLS Handshake remains unchanged, but the domain/server owner is able to monitor the certificates and be sure that no unrequested or unapproved certificates are issued for his/her domain or server.
I am for transparency! But how does this affect my EV certificate with Namecheap Inc.?
All Extended Validation (EV) certificates with an expiration date beyond December 2015 should support certificate transparency. This concerns already issued EV certificates as well. It is planned on or after February 1st, 2015 to stop displaying the Green Bar in Google Chrome, if a valid and verified SCT is not provided along with an EV certificate during secure session negotiation. The exact time frame has not been announced so far, and it depends on Google Chrome release schedule.
Comodo (now Sectigo) Certificate Authority - our SSL vendor - supports Certificate Transparency for EV certificates starting the middle of December, 2014. All current and future EV certificates, purchased and activated via Namecheap, will support Certificate Transparency, and public logs will be whitelisted. As per recent Google announcement, all SSL certificates, DV and OV included, will be required to comply with CT starting October, 2017.
Certificate Transparency is a background modification to the way EV certificates are issued. This process has no impact on SSL ordering and activation via Namecheap interface and no actions are required from you, even if your EV certificate has been issued long before this novelty. Your EV certificates have been added to Google’s Certificate Transparency whitelist by Certificate Authorities.
Note: Since 23 March 2018, all SSL certificates issued by Comodo CA (now Sectigo CA) comply with Chromium's CT Policy. Thus, no additional actions are required from the end user of Comodo (now Sectigo) SSL certificate to include certificates issued on or after such a date in any known CT Log to be compliant with Google Chrome mandate from April 2018.
How can I check if Certificate Transparency is supported?
Now you will see all available SCTs logs for the opened website.
Note: The SCT list section is displayed on Windows 10 and higher. On older Operating Systems, the section is named 220.127.116.11.4.1.1118.104.22.168.
As a conclusion…
At the near future, all Certificate Authorities will need to comply with CT by automatically publishing the issued certificates. This is, in part, due to Google’s strong positioning with their Chrome browser: future versions of the Chrome browser may even show warning indicators for sites with certificates that are not present in CT Log Servers. So far, any EV certificate is checked carefully for CT presence in public CT Logs.
Of course, this article gives you a very general idea of what is going on and what Certificate Transparency is. There are much more questions to be asked, and some of them were already answered here. As usual, we are 24/7 with you via Chat and Ticket for discussion, clarification and negotiation of what is best for you!