How Certificate Transparency Changes the World of SSL

4 votes, average: 5.00 out of 54 votes, average: 5.00 out of 54 votes, average: 5.00 out of 54 votes, average: 5.00 out of 54 votes, average: 5.00 out of 5 (4 votes, average: 5.00 out of 5, rated)

Publicly logging the SSL Certificates they issue helps CAs to be more accountable

The SSL ecosystem is a complicated one. Certificate Authorities must be trusted by the browsers in order to issue certificates to businesses, organizations and individuals which will then install and configure those certificates on various kinds of web servers in order to facilitate encrypted connections between their websites and the millions of users surfing the internet.

There’s a whole lot of different things to consider and keep track of when it comes to SSL—one of the biggest being mis-issuances.

You see, a mis-issuance has the potential to cause catastrophic damage to a number of different actors in the SSL ecosystem.

A mis-issuance can be damaging to a company or organization if a certificate is issued to a third party under their name. Take for instance a company like PayPal, which is an intermediary for millions of financial transactions every year. Were a CA to mis-issue a certificate that said PayPal to a party that was in fact not PayPal, that party could then spoof PayPal’s website and cause all kinds of harm.

In that instance, PayPal itself would suffer a hit to its reputation, this would mean a loss of consumer trust and a hit to its business interests—through no fault of its own. The mis-issuance would also affect consumers, as a number of them would inevitably be duped by the faked PayPal site (which would have a certificate that says it is the real PayPal) and would end up losing money—also through no fault of their own.

Then there would be damage to the standard SSL trust indicators – and to some extent SSL itself – after people had looked to them to verify the authenticity of the faked website and they had failed to notify people that it was a fake.

And finally the CA itself, after the mis-issuance was discovered, would take a considerable hit from both consumers that no longer trusted it and from the browser community which would actively seek to penalize it.

Long story short, one mis-issuance – provided it was high-profile enough – could potentially crater the entire SSL industry.

That’s why Certificate Transparency, an initiative backed by Google and supported by the rest of the browser community, is so important.

What is Certificate Transparency?

Certificate Transparency requires CAs to log all certificates they issue in publicly accessible Qualified CT logs. This creates a system by which multiple parties have the ability to act as safeguards and check the validity/revocation status of SSL Certificates.

Here’s a quick peek at how Certificate Transparency works:

First of all, there are four main groups that participate in Certificate Transparency:

  • Certificate Authorities
  • Log Servers (these are basically public repositories for the certificate records)
  • The browsers (acting as auditors)
  • Publicly run servers (these monitor newly added certificate logs to check for mis-issuances)

Here’s what happens when a CA logs a newly issued certificate:

  1. The Certificate Authority creates a “pre-certificate.” The pre-certificate contains all of the SSL Certificate’s information. The CA sends the pre-certificate to its Log Server.
  2. The Log server accepts the pre-certificate and returns a Signed Certificate Timestamp (SCT). The SCT promises to log the certificate within a certain timeframe. This timeframe is known as the Maximum Merge Delay (MMD)—it’s never longer than 24 hours.
  3. The SCT is accepted by the CA, which adds it to the body of the SSL Certificate. The SCT’s presence is a signal that the certificate has been published in a CT log.

There are three methods for delivering an SCT with an SSL Certificate, they are:

  • X509v3 Extension
  • TLS Extension
  • OCSP Stapling

By submitting their newly issued certificates to a publicly trusted log server, the CAs are both acting in good faith and also assuring that any mistakes made on their part will be caught more quickly—thus mitigating any potential damage.

Errors are always a possibility. Even the most diligent CAs are still going to have the occasional mishap. You can look up almost any CA and find at least one mistake in its history. But Certificate Transparency helps to assure that any mistakes made will be quickly found and corrected.

As of right now, Certificate Transparency is not yet mandatory. A number of CAs have proactively agreed to it, while others have been forced to commit to it after running afoul of CA/B forum regulations. But for the time being, Certificate Transparency is still optional.

In the future, however, it will likely become a requirement. This is because CT logs create a phenomenal safeguard—one which keeps the entire SSL industry safer. Keep in mind, the browser community is pushing for a universally encrypted internet. As encryption becomes more widely proliferated, the need for safeguards like Certificate Transparency grow.

After all, just one mis-issuance – if it were high-profile enough – could be disastrous to the entire industry. Certificate Transparency is just one more way to help protect against that possibility.