GlobalSign Blog

11 Aug 2017

What is Certificate Transparency?

Certificate Transparency (CT) probably first came on your radar a few years ago when Google announced it as a requirement for all Extended Validation (EV) SSL/TLS Certificates issued after 1 Jan 2015. Since then, Google has expanded the requirement to cover all types of SSL Certificates and most recently announced a deadline of April 2018. Certificates issued after that date that are not CT qualified will not be trusted in Chrome.

At GlobalSign, we’ve been working hard behind the scenes to equip all of our certificates with CT – Extended Validation (EV) since 2015, Domain Validated (DV) since August 2016 and Organization Validated (OV) is coming in October 2017 - so our customers will be ready for Google’s deadline next year.

In the meantime, for those of you who are still wondering what CT is all about, consider this your prep course.

Note: For the sake of simplicity, we’re using the term SSL instead of TLS throughout this post (with one exception) since it’s more commonly used. For more on this, read our related post.

What is Certificate Transparency?

Certificate Transparency is an open framework for monitoring SSL Certificates. Domain owners may find it useful to monitor certificate issuance for their domain and use that to detect misissued certificates. Prior to CT, there was not an efficient way to get a comprehensive list of certificates issued to your domain.

With CT, all certificates are publicly disclosed, providing greater insight and transparency into the Web PKI ecosystem as a whole. The Certificate Transparency Project aims to achieve three goals:

  1. To make it impossible (or at least very difficult) for a CA to issue a SSL Certificate for a domain without the certificate being visible to the owner of that domain.
  2. To provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
  3. To protect users from being duped by certificates that were mistakenly or maliciously issued.

The Certificate Transparency framework means misissued certificates can be detected quickly and efficiently as  compared to the old system where rogue certificates could be left in the wild to wreak havoc for weeks or months before being discovered. Early detection of suspect certificates allows CAs and domain owners alike to act quickly and revoke the certificates.

How Certificate Transparency Works

The main two CT components are the CT logs and Monitors.

CT logs maintain records of issued SSL Certificates. These logs are append-only, meaning entries can’t be deleted or altered in any way once a certificate has been added to a log.  SSL Certificates and precertificates (more on this below) may be posted to CT logs.  Upon receipt of a valid SSL Certificate or precertificate, the log returns a Signed Certificate Timestamp (SCT), which is proof that the log received the request.  CT logs use a cryptographic mechanism called Merkle Tree Hash that prevents log entries from being modified or deleted, so once posted they are always visible to the public.   Browsers may require SCTs (which indicate that the certificate was publicly disclosed) while processing SSL Certificates when establishing a TLS session, so these SCTs are an increasingly important feature in the Web PKI.  More on this later.

Monitors query CT logs and can download and store certificates for subsequent reporting.  Monitors will parse the certificates into subfields and allow their users to create and run queries for certificates.  Domain owners may be interested receiving notices for certificates issued to their domains, or for certificates that match their Organizational name, while compliance teams may be looking for compliance with the CA/Browser Forum Baseline Requirements or Root Program requirements.  Regardless, there are many purposes for Monitors.  Some third party services have released CT Monitoring tools or started bundling them into their existing solution packages. For example, Facebook launched a free monitoring service of their own at the end of last year.

What Are Precertificates?

As mentioned above, CT logs accept SSL precertificates and certificates.  A precertificate contains all the same data as the “real” certificate, but also contains one additional extension that makes the certificate unusable.  This extension is referred to as a poison extension and is used to distinguish it from the “real” certificate.  Since all certificates issued by a CA must contain unique serial numbers, and since both the precertificate and certificate will have the same serial number, it’s important to make one of them as invalid or not usable, thus the poison extension.

Why Are Precertificates Useful?

There are several methods for delivering SCTs to browsers for processing, but the most reliable and useful is by including SCTs into the certificate.  In order to obtain SCTs prior to issuance (so they can be included into the certificate), the CA must create a precertificate, post it to CT logs, receive SCTs and then include them into the final certificate.

Prior to issuing a certificate, a CA may submit a precertificate to CT logs as intent to issue the corresponding certificate.  In fact, creating and posting a precertificate that is not properly validated or formatted is considered a misissuance.

Who Can Submit Certificates to CT logs?

Anyone can submit certificates to CT logs, but only CAs will submit precertificates.  Search engines and website operators also often post certificates to CT logs.

Some CT log operators accept certificates under only certain roots, some don’t accept expired certificates, and all certificates (or precertificates) must be intended to be used as SSL Certificates (i.e. you cannot post S/MIME or Code Signing Certificates to CT logs).

Using SCTs

The SCT – the proof that the certificate has been logged - must be made available to the web browser in order for the browser to properly evaluate the SSL Certificate.  The exact browser behavior and requirements for SCTs varies by browser, but in all cases, the browser must receive the SCTs.  While the browser could theoretically post SSL Certificates to logs when creating a TLS session to get SCTs, the overhead in doing so would be prohibitive.  There are three main methods for delivering SCTs to the browser:

1.      Certificate Extension

The most common and the most reliable method for delivering SCTs to the browser is for the CA to include SCTs into the certificate.  Since the browser needs the SSL Certificate to establish the TLS session, the certificate is guaranteed to be present and can always be used for reading SCTs.

Some website owners may not want to make their website URLs known prior to launching their site, so they may not want to post their certificates to CT logs in advance. In this case, one of the other delivery options may be preferred.

2.      TLS (SSL) Extension

The website operator may provide SCTs to the browser within the TLS protocol. In this model, the website operator/webserver submits the certificate to CT logs and obtains the SCTs. The SCTs are included in the TLS handshake via a TLS extension called “signed_certificate_timestamp”. The “downside” to this delivery method is that webserver operators must change their default webserver configurations and not all webservers support this option.

3.   OCSP Stapling

OCSP messages may be used for the distribution of SCTs to the browser.  Two items are needed to support this method:

  1. The website operator must use a webserver that supports OCSP stapling and must configure their server to request and download a valid OCSP response. If this is not done, there is no guarantee that the browser will go fetch the OCSP message containing the SCTs (many browsers do not support OCSP, so this is not a reliable delivery mechanism unless the OCSP response is include in the TLS protocol).
  2. The CA must configure their OCSP service to support SCT stapling.  After the certificate has been issued, the CA will post it to multiple logs and receive SCTs.  When OCSP responses are generated, the CA will attach the SCTs to the OCSP message and then the browser will have both the revocation status and the necessary SCTs.

While both methods 2 and 3 require special server configuration, they can offer more flexibility compared to option 1 above if certificate logs become untrusted since the web site operator and CA can more dynamically reconfigure the logs being used.

The Google CT Policy

In order to be “CT qualified”, Google requires a certificate to appear in multiple logs (at least one Google log and one non-Google log) and the number of SCTs needed depends on the validity period of the certificate. For more details, please see Google’s Certificate Transparency in Chrome.

A list of logs can be found here.

So What Do You Need to Do to Be CT Compliant?

Well, now you know the basics of CT!  The best solution to make sure you’re compliant is to select a CA that adds SCTs to issued certificate in compliance with the Google CT policy.  The vast majority of GlobalSign SSL Certificates already comply with the Google policy and in a few months all certificates will comply, a full 5 months prior to the Google deadline of April, 2018.

So far, Google has been the only browser to announce timelines for requiring CT. Mozilla has drafted a policy, but no dates have been announced yet and we expect their requirements to be compatible with the Google requirements. You can follow the discussion here.  We will update this post pending any future announcements.

Have questions about certificate transparency and whether your certificates are compliant? Contact us anytime; we’re happy to help.

by Doug Beattie

Share this Post