Everything You Wanted to Know About Certificate Transparency

A comprehensive look at what Certificate Transparency is and how it helps the SSL Ecosystem

Certificate Transparency is a Google initiative aimed at increasing the safety of the SSL/TLS Certificate System. Namely, Certificate Transparency has been put in place to defend against mis-issuance.

This is an extremely important safeguard for the SSL/TLS ecosystem. It’s absolutely vital that when a Certificate Authority issues an SSL Certificate, that it issues that certificate to the correct party. Think about it, a large company like PayPal requires an SSL Certificate for both encryption and authentication. It’s obviously very important that a company that deals in financial transactions be able to encrypt communication. But it’s equally important that PayPal be authenticated so customers have assurance they’re dealing with the actual company and not an imposter.

So, you can probably imagine, if a CA were to mis-issue an SSL Certificate to a company that wasn’t PayPal—all hell would break loose.

This is why Google has pushed for Certificate Transparency, which essentially requires CAs to log all certificates they issue in publicly accessible Qualified CT logs.

Let’s take a look at how it works:

How Certificate Transparency Works

There are four main participants in Certificate Transparency. They are:

• Certificate Authorities
• Log Servers that act as public repositories for the certificate records
• The browsers of any client accepting certificates (they act as auditors)
• Publicly run servers that monitor newly added certi ficate logs to check for mis-issuances

The following occurs when a CA logs a certificate:

1. The CA creates what is called a “pre-certificate,” which contains the SSL Certificate’s information. The CA then sends this pre-certificate to its trusted Log server.

2. The Log server then accepts this information and returns a “signed certificate timestamp” or SCT. The SCT essentially promises to log the certificate within a certain period of time. This time frame is known as the Maximum Merge Delay or MMD—it may never exceed 24 hours.
3. The SCT is then accepted by the CA and added to the body of the SSL Certificate (or sometimes presented by other means). The SCT’s presence is, itself, a signal that the certificate has been published in a CT log.

There are three ways for an SCT to be delivered with the SSL Certificate:

• X509v3 Extension
• TLS Extension
• OCSP Stapling

The Benefits of Certificate Transparency

For obvious reasons, publicly logging SSL Certificates carries a great number of advantages for both CAs, browsers and end users.

From the standpoint of the CA, logging issued certificates requires just a single extra step, but allows them to cover themselves should a mistake be made and a certificate require revocation. In the past it would have taken much longer to discover a mis-issuance or mistake and then the CA would have to act quickly to revoke the certificate. This cuts down on the time it takes to discover bad certs and allows the CAs to act much more quickly.

It also allows browsers and end users to check the validity of issued certificates much more quickly. Soon, Google Chrome will actively block connections to websites with SSL Certificates that don’t also have SCTs. This will help to keep end users safer and will force websites to use SSL from trusted CAs. Overall it will help to make the internet more secure.

There’s really no downside to Certificate Transparency if you’re acting in good faith. It helps CAs, browsers and end users by creating a great degree of accountability and by ensuring that bad certificates can be revoked more quickly.

Images Source: https://www.certificate-transparency.org/