What is certificate transparency?

Verify for trust

You may have heard that Chrome started branding websites that don’t use SSL with the red badge of “not secure” starting in July 2018. Other platforms such as Apple’s Safari are following suit. This has led to a land rush of webmasters seeking out SSL certificates. But did you know that just any old SSL certificate won’t do? It’s critical that your certificate complies with the certificate transparency log policy. Otherwise, you might make your problem worse rather than better.

Certificate transparency log policy is a framework that makes it possible to verify that an SSL certificate presented by a site is indeed trustworthy.

 

A certificate that cannot be verified this way can result in your visitor receiving a full-screen warning that your site is insecure. That’s definitely not going to encourage your users to stick around!

The SSL certificate log policy makes it possible to verify that a site’s certificate is indeed trustworthy, and is necessary because SSL certificates can be faked.

In fact, it’s a common practice employed by criminals. When crooks create phony websites that impersonate real services, such as spoofed eCommerce sites, they often bolster credibility with fake SSL certificates. Such certificates are often stolen or self-signed. Certificate transparency addresses this problem and others that come from bogus SSL certificates that have been mistakenly issued, compromised, or come from certificate authorities (CAs) that have been compromised or gone rogue.

To address trickery like this, the certificate transparency log policy was created. It provides an open monitoring system that makes it possible to determine if a particular SSL certificate was legitimately issued. Under this framework, every CA must maintain a public and verifiable log of every SSL certificate it issues.

Related: Use Google’s Transparency Report to check for certificate transparency 

Certificate Transparency SSL

How certificate transparency works

Certificate transparency (CT) doesn’t replace the existing SSL system that validates a domain and enables a secure connection. Instead, it augments it by adding a public oversight framework that incorporates three components:

  1. Certificate logs.

  2. Certificate monitors.

  3. Certificate auditors.

Each of these is a discrete software module in the framework.

1. Certificate logs

Logs lie at the heart of the certificate transparency system. A certificate log is a network service that provides a record of SSL certificates that can be queried on demand. These logs have three critical features:

  • Certificate logs are append-only. SSL certificates can only be added to the end of the log. A certificate cannot be deleted, modified, or inserted at an earlier point.
  • Certificate logs are cryptographically assured. This means a cryptographic mechanism, in this case the Merkle Tree Hash, is used to ensure that the log is free from tampering.
  • Certificate logs are public. Anyone can query a log to verify a certificate.

There are multiple certificate logs. Each one must advertise its URL and public key, and anyone can interact with it using GET and POST methods. Anyone can submit a certificate to a log, though mostly this is done by certificate authorities and server operators.

Once a certificate (or pre-certificate) is submitted to the log, the log returns a signed certificate timestamp (SCT) as proof it received the request to add the certificate. The SCT is tied to the certificate throughout its lifetime. Browsers can request the SCT as part of the transport layer security (TLS) handshake when establishing a trusted connection with a site.

The most common and reliable way, although not the only way, to deliver the SCT to a requesting browser, is by including it in the SSL certificate.

This creates a kind of Catch-22 since you need the SCT before issuing the certificate but you can’t get the SCT until you submit the certificate to the log. To address this, pre-certificates were created. A pre-certificate contains the same data as the final certificate and even has the same serial number, but it includes an extra extension, called the poison extension, that makes it unusable. A CA can submit the pre-certificate to the CT log, get the SCT, and include it in a final certificate — the one that will actually be issued to the web site.

Other methods of conveying SCTs to a browser include via TLS (SSL) extension and online certificate status protocol (OCSP) stapling. Both of these require additional server-side configuration for the web host. OCSP stapling requires additional configuration by the issuing CA as well.

Related: How to enable HTTP on your server

SSL certificates are typically submitted to multiple logs for redundancy and thus contain multiple SCTs. If a browser can’t access one of the logs, it can use another.

2. Certificate monitors

Monitors are the framework component used to verify that all logged certificates remain visible in the log. They’re also used to watch for suspicious activity in certificate logs. They can download certificates and store them for later use or for parsing into fields which can be queried.

For example, a user might query the data to look for all certificates that match their organizational name or domain. Since monitors periodically download all new entries, they end up with a complete copy of the log. Most monitors are operated by CAs, but they can also be operated as stand-alone, paid services or run by large internet entities like Google.

3. Certificate auditors

Auditors are the third framework component. They are responsible for verifying the overall integrity of logs. They do this by fetching and verifying log proofs. A log proof is a cryptographic hash that proves the log is following all the rules and is in good standing.

Logs must provide this data on demand.

 

Under the design of the certificate transparency log policy framework, most auditing functions are built into browsers. The framework is flexible though, and it’s possible that an auditor could be run as a stand-alone service or as part of a monitoring service.

A typical SSL certificate scenario

The certificate transparency framework is flexible, so there’s not a single, rigid path that must be followed. Often, however, the process goes like this:

  1. A server operator requests an SSL certificate from a CA.
  2. The CA obtains an SCT from a log server (via pre-certificate) and incorporates it into the SSL certificate. The certificate is issued, with SCT attached, to the server operator for installation on the server.
  3. When a visitor’s browser initiates the TLS handshake, it receives the SSL certificate and SCT. The TLS client validates the certificate as usual under the TLS protocol. Then it also checks the SCT to ensure that it was issued by a valid CT log and that it matches the SSL certificate. If it finds any discrepancies, it rejects the SSL certificate.

If you obtain your SSL certificate from a trusted provider, such as GoDaddy, you can rest assured that it will make use of the certificate transparency log policy. This protects both you and your users. With it, your SSL certificate can be proven trustworthy in a way that wasn’t possible before. This extra safety net protects both web providers and users — a win all around.

Related: How to install an SSL certificate on cPanel