What is Certificate Transparency

  General Questions

How Is Certificate Transparency Implemented?
Advantages of Certificate Transparency (CT)
How to Check for Certificate Transparency (CT) Compliance?

Certificate Transparency is a relatively new framework that’s designed to fix some structural flaws within the existing system of SSL certificates, in return making it more open to the public. It was first announced by Google Inc. in the beginning of 2010 and is now gaining some momentum in terms of Internet implementation. Let us dive into some of the most important details regarding this subject.

Originally defined by Netscape and other companies in nineties, the process implies that Certificate Authorities (also known as CAs) should present the certificate requester with the certificate, prior to its issuance. This way, it can reviewed and approved. Once the certificate is issued, it must be published in an independent database in order to prove that the person in charge of the certificate request is aware of the fact that it was issued.

The database (or repository) allows anyone to check the public key along with the other fields that are included within the certificate. This checking can be performed without connecting to and establishing a secure server connection where the certificate in question is installed.

Therefore, it’s possible to gain access to the public key in an alternative way besides secure-session negotiation. Certificate Transparency, in effect, makes the whole system more open and provides any concerned parties with a reliable way to monitor and audit issued certificates.

At some point in the future, all CAs should comply with CT by automatically publishing the issued certificates. This is due in part 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.

How Is Certificate Transparency Implemented?

In short, Certificate Transparency (CT) is achieved via the posting of any issued certificates to publicly-available Qualified CT logs. The main participants in the process are:

  • Certificate Authorities
  • Publicly-Available Repositories (with certificates and Log Servers)
  • Auditors (usually, client browsers that accept the certificate)
  • Publicly-Available Monitors (monitoring of new certificates that were added to the aforementioned Log Servers and the detection of certificates that were wrongly issued)

A CA creates a ‘pre-version’ of the certificate with all necessary information that will be reflected in the future, after its issuance. This version then gets sent to a trusted Log Server to accept this information and subsequently sends back a ‘Signed Certificate Timestamp’ (SCT). This timestamp guarantees that the certificate will be added to the Log Server within a certain time period. This time period is also referred to as Maximum Merge Delay (MMD). It should be noted, however, that MMD does not defer issuance of the actual certificate; it exists only to provide Log Server operators with some flexibility (in case of technical outages, for example) in conforming to the rules set forth for any entity willing to provide a publicly-accessible CT Log server. According to the rules, a maximum MMD timeframe is set to last 24 hours, meaning that any new certificate will be present in CT Log Servers within 24 hours since the time when SCT was generated. The timestamp accompanies the certificate during its life cycle directly to expiration (revocation). Also, any reissued certificate will get a new SCT.

Once a CA receives the SCT from the Log Server, it incorporates the SCT into the body of the certificate or presents it via these alternative ways. The timestamp that is present on a certificate signifies that it has already been published in CT Log Servers.

In general, there are 3 methods in which SCT for a certificate can be delivered:

  1. The x509v3 extension method. Here, no further actions are required by server operators.
  2. The TLS extension method. Here, the SCT is delivered during the TLS handshake using the signed_certificate_timestamp type.
  3. The OCSP stapling method. Here, SCT information gets delivered to clients by the server operator, along with the appropriate Online Certificate Status Protocol (OCSP) response.

                    

          

A more detailed explanation behind these three methods can be found here. The general takeaway is that a SCT must be presented, along with the SSL certificate, during a secure- session negotiation.

Advantages of Certificate Transparency (CT)

This proposed system offers many benefits to the existing SSL certificate system. Although they are primarily focused on Certificate Authorities (CAs) and domain operators, individual users may also benefit as a result.

Below is a short list of advantages that CT provides:

  • A more open system, which provides any concerned parties with a more reliable way to monitor certificates for required domain names.
  • Easier to spot certificates that should not have been issued, given there is a publicly logged record.
  • No additional steps required by end users for the initial SSL set up.
  • No effect to latency when establishing a secure connection.

Please note, however, that some minor changes to the infrastructure are required from server administrators in case of OCSP stapling/TLS extension ways of SCT delivery. Also, any CA who wants to incorporate SCT in their certificates via the x509v3 extension must first make changes to their infrastructure when submitting ‘pre-certificates’ to the Log Servers for issuance.

At some point in the future, all CAs should comply with CT by automatically publishing the issued certificates. This is due in part 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.

Our SSL vendor, Comodo CA (now Sectigo CA), supports CT for all their newly-issued certificates, including domain validated ones (DV certificates). Therefore, all of our certificates are present in the CT Log Servers and will not result in any warnings in Google Chrome.

How to Check for Certificate Transparency (CT) Compliance?

It’s possible to check for the SCT directly in Google Chrome. To do so, please follow the listed steps:

  1. To inspect the CT status of the certificate, open Google Chrome’s developer tools (located under “More tools” in the Chrome navigation menu).
  2. Toggle to the ‘Security’ tab.
  3. Now enter the website with the certificate in question. (You should then see the detailed security information about this site.)
  4. Locate a section called “Certificate Transparency” near the bottom of the page. It will list all available SCT for that particular website in question. An empty section will mean that the website does not provide any SCTs (and it does not comply to CT).

You can check any certificate present in the Log Servers by using Google’s web service. In addition, you can also use a variety of web services from reliable third-parties and CAs from across the Internet (e.g. the Comodo (now Sectigo) CT checker). Also, there are paid services that provide automated monitoring of all certificates for a particular domain name(s). The CT framework provides technical possibilities for these new services to emerge.

Given this framework’s complexity, feel free to visit the Certificate Transparency (CT) official FAQ here to deepen your knowledge of the subject.

As always, if you have any lingering questions, please contact our 24/7 Customer Support Team via ticket or start a Live Chat by clicking on the blue bubble icon at the lower right corner of the page.