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:
- Log servers as public repositories for certificates
- Auditors - browser of any client that accepts certificate
- Monitors - publicly run servers whose aim is monitoring newly added certificates to log servers for detecting mis-issued certificates for certain websites.
Firstly, a Certificate Authority creates a ‘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 timeframe, 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 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 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. How can I check if Certificate Transparency is supported?
This option is supported by Google Chrome (starting from version 33, released in March 2014). This information is present in the Connection information pop-up in Chrome. Click the padlock:
Then navigate to the Connection Information tab:
The Certificate Transparency status is now a part of the website identity string. For example, when a valid Signed Certificate Timestamp accompanies the certificate, the string will read as ‘publicly auditable’:
As a conclusion…
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!