Certificate Transparency for domain owners

Certificate Transparency for domain owners

- - Articles

Certificate Transparency (CT) provides a means to detect certificates that are mistakenly or maliciously issued by a Certification Authority (CA). As a domain owner, you should care about this for two different reasons: i) You can detect if an attacker is issuing certificates to impersonate your websites; and ii) browsers like Chrome and Safari mark your website as “insecure” if your certificate doesn’t comply with their CT policy.

Want to know the details? Please keep reading 🙂

The problem that Certificate Transparency addresses

The HTTPS protocol enables secure communications in the web. In particular, communications between the client (usually a web browser) and the server are encrypted, and the website can “prove” that it’s the one it claims to be. The latter is achieved by means of a domain certificate (aka server certificate). As you already know, it’s comprised of two main elements:

  • The domain name of your website. If you inspect a certificate, you’ll find it in either the common name or the alternative name of the subject of the certificate.
  • The public key of the certificate. Your web server has access to the corresponding private key. Any other server with your public key but with a different private key won’t be able to impersonate your website, since the HTTPS handshake would fail.

However, these two pieces of information alone don’t provide any kind of security yet. I could still issue a certificate for! So your certificate needs a third element: it must be signed by a CA. The CA acts as a trusted third party that ensures your certificate is legit. Since everyone trusts the CA, your browser will accept your server’s certificate during the HTTPS handshake and your users can be confident that they’re visiting your website…

Really? Well, this might not be the case. What if the CA mistakenly issues a certificate for your website to an attacker? What if the CA gets compromised? Then you have a problem, because this attacker might impersonate your website but, from your users’ viewpoint, everything would seem like if they were securely browsing your site.

Hmm, but does this really happen in practice? Could a CA issue a certificate that shouldn’t be issued? Let’s see some examples:

Now you might be thinking that even if the attacker gets a rogue certificate for your website she still has to hack DNS records to point your users to her servers. In practice this can be done with DNS hijacking and cache poisoning attacks, but it’s not even required in many cases. If the attacker has already infected the victim’s computer, e.g. she might edit the hosts file to direct the victim to the malicious website. And there are other man-in-the-middle attacks to exploit the issue.

Since the problem exists and it can be exploited, we need a solution. The goal of CT is to provide domain owners with a means to detect rogue certificates issued for their websites.

CT logs to the rescue

One solution for the problem above is to maintain an open log of all domain certificates issued by CAs. In this way, any domain owner may check whether there are any certificates she didn’t request. If that ever happens, the owner may ask the issuing CA to revoke the rogue certificates.

In practice there’s not a single CT log but a set of CT logs operated by different organizations, including Cloudflare, Comodo, DigiCert and Google. Then, as a domain owner, do you have to monitor all these logs on your own to find out what certificates have been issued for your domains? That would put a high burden on the owner. Luckily, there are several CT logs monitoring services out there. Facebook’s CT tool is free and one of the best known monitors. You can look for the certificates of your domains or subscribe to receive a notification whenever new certificates for such domains are added to a CT log.

CT logs don’t make much sense if CAs don’t submit the certificates they issue to the logs. To incentivize CAs to do so, Google announced that Chrome would regard any website as insecure if the corresponding certificate wasn’t present in multiple trusted CT logs. The result is that any CA that wants to keep its business submits its certificates to CT logs – of course, this includes Let’s Encrypt.

The Certificate Transparency project

CT started as a Google’s project and then became a collaborative effort led by the trans working group of the IETF. You can find the main spec of CT in RFC 6962.

Browsers’ policies regarding CT logs


Given that CT started out as a Google project, it’s no surprise that Chrome is the browser that has pushed forward CT logs more aggresively. Chrome initially required EV certificates issued after January 1, 2015 to be published in CT logs. Since April 2018, it requires all certificates to be in multiple trusted CT logs. Otherwise, your website will be regarded as “insecure” by this browser.

Google understands that a CT log is trusted if it complies with RFC 6962, provides (at least) 99% uptime, and it’s able to add a certificate within 24 hours, among others.


I failed to find an authoritative resource from Mozilla stating the current policy in Firefox, other than this (apparently) outdated wiki entry about CT. According to previous announcements and some issues in bugzilla, Firefox supports RFC 6962 but I’m not sure if it somehow flags certificates that haven’t been pushed into a CT log. However, I did find a Firefox plugin that does just that.


All server authentication certificates issued after October 15, 2018 must meet Apple’s CT policy in all their platforms. This means that Safari will fail to establish an HTTPS connection if the domain certificate hasn’t been published in a number of CT logs. The number of required CT logs varies in terms of the lifetime of the certificate.

IE, Edge

While Microsoft supports the CT initiative, they don’t seem to be enforcing usage of certificates with CT information in their browsers as of this writing.


The Certificate Transparency initiative improves the security of the web ecosystem by allowing detection of duplicate (maybe rogue) domain certificates. CAs are responsible for publishing the certificates they issue into open CT logs that can be monitored by website owners to detect such duplicates. In addition, some browsers will alert websites’ visitors when the domain certificate hasn’t been included in a CT log, thus regarding the website as insecure.

Since most CAs already align with this initiative, you shouldn’t have any problem with your domain certificates. But if you do, then you should stop using your current CA 😉

If you liked this article, please share it! You can also sign up below if you want us to send you an email as we publish more stuff.

Don’t miss a post! Subscribe to the Moss Blog