Let's Encrypt Readies for Certificate Transparency with Embedded SCTs
Let's Encrypt, a leading issuer of SSL/TLS certificates, is preparing to take a big step forward by adding support for Certificate Transparency. This capability, now merged into Let's Encrypt's
Boulder CA suite, will resolve a long-standing feature request by embedding Signed Certificate Timestamps (SCTs) into newly minted certificates. Because the SCT will be attached directly to the certificate, no additional server modules or configuration will be needed by site administrators.
Certificate Transparency support will allow websites using Let's Encrypt certificates to implement the Expect-CT HTTP header. This header provides additional security by instructing web browsers to verify the certificates they receive against public certificate transparency logs. Forged or otherwise malicious certificates are often absent from these logs, and will never contain the correct SCT, making them easier to detect when a site uses
The feature isn't yet live, but the Let's Encrypt project has announced Q1 2018 as the release target, and the latest announcement suggests a rollout by the end of March.
What Certificate Transparency does
In a perfect world, every time you connect to a website (or other service) over TLS, you'd be able to trust the certificate presented by the remote host as long as it's issued by a valid Certificate Authority that you also trust. But digital trust isn't perfect. Private signing keys sometimes get compromised, and CAs occasionally exhibit unscrupulous behavior, resulting in forged or mis-issued certificates that look valid but are controlled by a malicious actor. These certs can be used to intercept traffic, inject resources, or perform other man-in-the-middle style attacks.
Certificate Transparency (RFC6962) helps mitigate this problem by introducing additional verification into the chain of trust. The foundation lies in certificate logs, which are implemented as immutable, cryptographically signed ledgers that can be viewed and audited by the public. (If you're into buzzwords, you can think of a certificate log as a blockchain for SSL certs.) Public certificate logs are currently operated by Google, Cloudflare, DigiCert, Certly, Izenpe, WoSign, Venafi, CNNIC, StartCom, and Comodo, with other services like crt.sh providing an index to their data.
When a participating CA like Let's Encrypt mints a new certificate, they submit it to one or more certificate logs, creating a permanent visible record of its issuance. The certificate log, in turn, responds to the CA with a signed certificate timestamp (SCT) corresponding to the log entry. These logs and signatures are routinely monitored by domain owners, security researchers, and intellectual property firms. The idea is that all of this auditing means bogus certificates will be spotted early and can be quickly revoked, minimizing the fallout from counterfeits.
Automated certificate verification through Expect-CT
Certificate log monitoring only solves one aspect of the forgery threat model, because only certificates that are proactively submitted to the public logs can be inspected. An attacker who creates a malicious certificate isn't likely to publish it and tip their hand. Such certificates are often narrowly deployed to target specific individuals or groups, keeping them hidden from organizations that perform routine auditing. A system is also needed for individual end users to detect problem certificates, and this piece of the puzzle can be addressed with the
Expect-CT HTTP header.
In 2017, engineers at Google proposed a new HTTP header called
Expect-CT (draft specification). By implementing this header, a website operator can tell visitors' browsers that the site's legitimate TLS/SSL certificate is published in certificate logs, and that any other certificate is counterfeit. The browser can then use several methods to validate the certificate it received from the server against the cert(s) listed in the public logs.
If the certificate for an
Expect-CT-enabled site isn't present in public logs, or if its cryptographically signed certificate timestamp (SCT) doesn't match the one in the public logs, the browser can flag the connection as suspicious. The specification allows for the browser to either abort the connection, notify the site administrator through a reporting endpoint, or both. The
Expect-CT header and accompanying certificate verification is currently supported by Firefox, Chrome, and Opera, and has already been activated by many websites.
How Let's Encrypt Certificate Transparency works
The Certificate Transparency framework offers three mechanisms for automated certificate validation. Let's Encrypt has selected the most seamless of those options, which is to attach or "embed" a signed certificate timestamp (SCT) as an X.509v3 extension to the certificate itself. The new certificate issuance workflow will involve obtaining the SCT from a public certificate log and embedding it into the cert:
- User requests a certificate from Let's Encrypt
- Let's Encrypt creates a "pre-certificate" and submits it to a certificate log
- The certificate log responds with a cryptographically signed certificate timestamp (SCT)
- Let's Encrypt creates the certificate
- Let's Encrypt attaches the SCT to the certificate
- The final certificate is published to the certificate log
Currently, steps 2, 3, and 5 don't happen; so for now, enabling Certificate Transparency means that special patches to the httpd software are required. Once Let's Encrypt certificates have the SCT baked in, none of this will be necessary. A site operator will be able to install or update their certificates as normal (e.g. with certbot) and benefit from Certificate Transparency automatically.
A more thorough overview of the various Certificate Transparency mechanisms is available in the article How Certificate Transparency Works at Google's Certificate Transparency project site.