Questions about Certificate Transparency

What is Certificate Transparency?

Certificate Transparency (CT) is a system which uses public logs to record all certificates issued by a Certificate Authority (CA). Browsers, CAs and other parties can use CT (alongside other existing techniques) to confirm a certificate was correctly issued and thus enhance trust.

Why CT?

CT aims to make the issuance and existence of SSL certificates open and readily available information – transparent, if you will. This lets CT serve as a “CA watchdog” to make sure that CAs are operating as expected, since CT makes it very difficult for a CA to issue a certificate without a domain owner’s knowledge.

CT logs provide open data which can be used by domain owners, CAs or third parties, to determine whether certificates have been mistakenly or maliciously issued. The goal is to strengthen the security of the entire internet by offering a new tool to help protect users from incorrect or fraudulent certificates. Certificate Transparency satisfies these goals by creating an open framework for monitoring the TLS/SSL certificate system.

How does CT work?

Basically, CAs send certificates to a CT log server, which logs the delivery and sends back a Signed Certificate Timestamp (SCT). This SCT is used as proof of the date of issuance, usually by attaching it to the issued certificate. (There’s more than one way to deliver SCTs – but that’s for a more detailed article.)

It’s important to note that a certificate is stored in a log forever – items can be added to a log fairly easily, but removal is designed to be difficult (or impossible).

Other parts of the CT design specify monitors (which keep an eye out for suspicious certificates) and auditors (which verify that logs are trustworthy) – these may be run by CAs or third parties (monitors) or actually built into browsers (auditors).

Much more detail about how CT works can be found here.

When is CT happening?

As of April 30 2018, Google will require CT for all certificates, including Organization Validation (OV) and Domain Validation (DV).

If you have an Extended Validation (EV) certificate you’ve been using CT already – Google imposed CT back in 2015 for all EV certificates.

CT has been applied to some sets of non-EV certificates already as well – for instance, all certificates issued by Symantec since June 2016 have been required to utilize CT by browser root programs, due to problems they encountered.

Any issues to be aware of?

Although CT should help prevent some issues, like any new technology there may be unintended consequences. Although all publicly-trusted certificates display relevant information about their subject (including, for instance, the hostname in a server certificate) CT concentrates this information into a single open log – not generally a concern but something to be aware of.

Will this affect how I get my certificate?

Not at all – as a customer, you will NOT need to do anything differently. CT happens ‘behind the scenes’ from a user’s perspective, and SSL.com (or our USERTrust partner) will perform all the required steps to ensure your certificate meets CT standards and performs as expected.

As always, if you have any questions please contact us at support@ssl.com or via live chat.