site logoTune The Web

Certificate Transparency (CT)


A well known problem with the public key infrastructure which underpins HTTPS is that any certificate authority can issue a certificate for any domain. This means, it may be possible for a third party to get a certificate for your website domain, redirect traffic to that website, and the user will be non the wiser and see a green padlock and happily give up login details and password. Now certificate authorities (CAs) are supposed to check you have authority over the domain you are ordering a certificate for, so this should never happen, but it can: either because CAs were lack in those checks, or because a CA has been compromised and others are issuing certificates on it's behalf. Either way the browser will accept the new certificate and the site will look secure when in fact it is not.

There are a couple of different ways to address this situation, including:

  1. Public Key Pinning (or HPKP) allows a website to specify the certificates that are acceptable to a website, and the web browser can cache these for a defined length of time, so an unrecognised certificate will be rejected. This is getting wider support but has some big downsides.
  2. DANE which is similar to HPKP except certificates are stapled at DNS. It doesn't seem to have much traction or support, which is it's main downside though personally I think it's possibly a better solution to HPKP.
  3. Certificate Transparency comes at it from another angle and instead attempts to give greater transparency to a website owner when a certificate is issued for their website. If they did not request such a certificate, then they are at least aware of it and can seek to get it revoked. It is not yet used much but seems to be getting a push recently so may be used a lot more in the future.

How to set it up

Certificate transparency is not something you as a website owner can set up, it can only be set up by your CA when you purchase a certificate. If your preferred CA does not use Certificate Transparency, then your only option is to purchase from a different CA that does.

Certificate transparency depends on a number of public audit logs. When a certificate is issued, that certificate should be added to the public audit logs, and so website owners (or more likely the CAs they normally use to issue certificates) can monitor those audit logs and see when a new certificate is issued.

This massively depends on a CA bothering to update audit logs, which is one of it's downsides, but web browsers (and in particularly Chrome) are trying to push this along by providing messages in the browser. If your certificate was issued using certificate transparency, you get a message like this if you look at the server certificate:

How Chrome displays valid certificate transparency

The way it knows this is by checking the audit log for this certificate. In fact it has to check at least two audit logs just in case one was compromised.

If your certificate was issued without using certificate transparency, you get a worrying message like this if you look at the server certificate:

How Chrome displays no valid certificate transparency

Well worrying, for anyone who bothers to look at the certificate information (which is very few!). Most websites do NOT use Certificate Transparency at present. Even Google (who have been big advocates of Certificate Transparency) only recently started using it on their main search engine websites.

Once you are in the public audit logs, there are three ways you can return the signed certificate timestamp (SCT) back to the web browser:

  1. Your CA can embed the SCT in the certificate itself. This does mean the certificate cannot be issued until the auto logs have been updated so could delay certificate issuance.
  2. You can configure your web server to issue the SCT. This allows the certificate to be issued immediately, and the SCT to be provided later. However at the time of writing no web servers support this functionality.
  3. Your CA can provide this information in the OCSP response which is used by OCSP Stapling.

The one thing all of these have in common, is that they do not require an extra network call to the CA or the audit logs to get the SCT. This is great as HTTPS already has enough performance issues as is.


Support is pretty limited at the moment. Only Chrome shows certificate transparency information at present, and even then it hides it away under certificates settings. Very few sites have certificate transparency yet and, until recently Chrome used to display a much scarier message ("The identity of this website has been verified by issuer but does not have public audit records"), but even that didn't really concern most people and nobody noticed.

Chrome however have stated that that EV certificates will lose EV status unless they implement certificate transparency, which has led to accusations that thousands short-changed by EV certificates that don’t display correctly in Chrome. This should certainly speed up CT adoption and I for one applaud Google for forcing the issue with moves like this, and SHA-1 sunsetting. There would always be a reason to live with the status quo unless you force the issue like this.

Saying that there currently only a few Certificate Transparency audit logs in existence, with only 7 logs at the time of writing. While this up from the 4 logs available just under a year ago, the fact that Chrome requires in dependent verification from 2-5 logs depending on the certificate lifetime shows that we really need some more audit logs, before we create a single point of failure here.

The downsides

The main downside is the lack of support. Google's push with EV certificates has forced the issue and in the last year we have seen a growing number of CAs supporting CT and this will surely only increase. However, until all CAs support CT and most browsers insist on CT for all certificates, the system is kind of flawed as any CA can still issue a certificate which will be accepted by most browsers.

CT also does not stop a fraudulent certificate being issued, or even being used, like HPKP does. The audit logs are intentionally open to additions (though not deletions) so that CAs can easily add audit logs, and it is up to the website owner to monitor this - though at present it's CAs who are providing the tools to do this monitoring and I think they are best placed to do that. If a fraudulent certificate is seen, then the website owner will need to persuade the CA to revoke it, and then you get into the whole argument of whether certificate revocation works or not.

Finally the other major downside, is that some anti-virus software, or corporate proxies, replace certificates on sites, so they can scan traffic. Lots of people (myself included!) don't like this for various reasons (see the Superfish incident) but it does happen. At present this treats CT certificates like this:

How Chrome displays valid certificate transparency replaced by Avast AV software

Now there is no reason why they could not remove CT information or why browsers could not ignore CT checks for locally issued certificates like they do for HPKP, but at present they don't. Luckily they also don't remove the green padlock though they really should when this error happens, and that's surely a matter of time (hopefully after they implement a work around for anti-virus software).


Certificate Transparency is an interesting approach to the problems of public key infrastructure underpinning HTTPS. While support is limited at present, it is an easily security feature to implement, with none of the downsides of HPKP, though admittedly does not do as good a job as that in protecting an incorrect certificate being used. I am a big fan of security arrangements like this, which add extra protection for very little downsides (so much so that I choose DigiCert as my cert provider so I could investigate it more). It may not provide 100% protection (and in all honesty what does) but it provides a lot less risk at the same time.

Update 20th September 2015: Google recently discovered an incorrectly issued certificate for This was issued as a test certificate by Symantec who promptly responded admitting failure and took decisive action. While, there are still questions as to the effectiveness of Certificte Transparency, this incident has been taken as confirmation that it can and does work and, given the relatively few downsides of Certificate Transparency, this is a very positive confirmation.

This page was originally created on and last edited on .

How useful was this page?