(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

June 6, 2018 1

Only Certificate Authorities need to worry about Certificate Transparency

in Industry Lowdown

End users, resellers and enterprise clients don’t need to take any action for CT

One of the most common questions we’re getting about all of these Certificate Transparency announcements is: “what do I need to do comply with CT?”

If you’re not a Certificate Authority, the answer is: nothing.

The party responsible for logging the certificates is the issuing Certificate Authority. And when you think about it, that also makes the most sense. The CA has to handle validation and issue the certificate off its own PKI, it has the biggest vested interest in making sure that the certificate is trusted by browsers. After all, it doesn’t take too many mis-issuances to attract the attention of Google and Mozilla.

How does Certificate Transparency work?

To help you better understand why you don’t need to worry about Certificate Transparency unless you’re a Certificate Authority, let’s look at how it all works:

1. The process begins when the CA creates a “pre-certificate.” This pre-certificate contains all the same information that will be included in the SSL certificate. It gets sent to the CA’s preferred CT log server at the outset of the process.
2. The CT log server responds to the pre-certificate by returning a Signed Certificate Timestamp or SCT. You might have see SCT thrown around in relation to Certificate Transparency before. An SCT is essentially a tokenized promise to log the certificate within 24 hours of receipt. This is known as the Maximum Merge Delay (MMD).
3. The CA takes the SCT and adds it to the body of the SSL certificate when it’s issued. That SCT serves a signal to the browsers that the certificate its attached to is published on a CT log. The SCT can be delivered three ways: via X509v3 extension, TLS extension or OCSP Stapling (see image below).

For the sake of better security, some browsers (like Apple’s Safari, for instance) will require SCTs from multiple CT logs in order to be trusted. This just means that the CA issuing the certificate has to send pre-certificates to multiple CT logs. So for instance, DigiCert may log a certificate it’s issuing on its own CT server, and then it may also send pre-certificates to Apple and Google for inclusion on their logs as well.

The CAs are the only ones required to do the logging?

Yes. There are, for all intents and purposes, two ways to log a certificate if we’re being honest. The alternative way is using web crawlers, which can see certificates and report them back to logs, too. The problem is crawlers can’t see everything on the web so you would never get a complete picture.

Certificate Transparency has long been a Google initiative, and with the entire internet moving towards HTTPS it makes sense to push for a system that requires greater accountability from issuing CAs—especially in light of some of the issues that have occurred over the past few years with CAs like WoSign and StartCom making egregious mistakes. Certificate Transparency provides a greater level of oversight, making it easier to detect mis-issuances and revoke them.

One of the biggest issues facing the SSL industry right now is the lack of a reliable revocation mechanism. Certificate Transparency doesn’t fix that entirely, but it’s certainly a step in the right direction.

• #Certificate Transparency
• #Certificate Transparency Logs