Certificate Transparency
This article may be too technical for most readers to understand.(August 2023) |
Certificate Transparency (CT) is an
The security of HTTPS depends on the trust that certificates are only given out by the certificate authority that was requested by the owner of some website or IT infrastructure. Certificate Transparency has the potential to expose certificates that were given out without them being requested by the genuine owner, such as malicious certificates by a compromised certificate authority (CA), which happened in 2010 at DigiNotar.
Technical overview
The certificate transparency system consists of a system of
Logging procedure
Although anyone can submit a certificate to a CT log, this task is commonly carried out by a CA as follows:[4][5]
- An applicant, "The natural person or Legal Entity that applies for (or seeks renewal of ) a Certificate",[6] requests a certificate from a CA.
- CA issues a special precertificate, a certificate which carries a poison extension signalling that it shouldn't be accepted by user agents.
- CA sends the precertificate to logs
- Logs return corresponding SCTs to the CA
- CA attaches SCTs collected from logs as an X.509 extension to the final certificate and provide it to the applicant.
Finally, a CA may decide to log the final certificate as well. Let's Encrypt E1 CA, for example, logs both precertificates and final certificates (see CA crt.sh profile page under 'issued certificates' section), whereas Google GTS CA 2A1 does not (see crt.sh profile page).
Mandatory certificate transparency
Some browsers require TLS certificates to have proof of being logged with certificate transparency,
Browser | Current SCT requirements | Current OCSP/TLS extension requirements |
---|---|---|
Chrome/Chromium |
| |
Firefox | None[11] | None |
Safari |
|
Two SCTs from currently approved logs |
Log sharding
Due to the large quantities of certificates issued with the Web PKI, certificate transparency logs can grow to contain many certificates. This large quantity of certificates can cause strain on logs. Temporal sharding is a method to reduce the strain on logs by sharding a log into multiple logs, and having each shard only accept precertificates/certificates with an expiration date in a particular time period (usually a calendar year).[13][14][15] Cloudflare's Nimbus series of logs was the first to use temporal sharding.
Background
Advantages
One of the problems with digital certificate management is that fraudulent certificates take a long time to be spotted, reported and revoked. An issued certificate not logged using Certificate Transparency may never be spotted at all. Certificate Transparency makes it possible for the domain owner (and anyone interested) to get in knowledge of any certificate issued for a domain.
Certificate Transparency logs
Certificate Transparency depends on verifiable Certificate Transparency logs. A log appends new certificates to an ever-growing Merkle hash tree.[1]: §4 To be seen as behaving correctly, a log must:
- Verify that each submitted certificate or precertificate has a valid signature chain leading back to a trusted root certificate authority certificate.
- Refuse to publish certificates without this valid signature chain.
- Store the entire verification chain from the newly accepted certificate back to the root certificate.
- Present this chain for auditing upon request.
A log may accept certificates that are not yet fully valid and certificates that have expired.
Certificate Transparency monitors
Monitors act as clients to the log servers. Monitors check logs to make sure they are behaving correctly. An inconsistency is used to prove that a log has not behaved correctly, and the signatures on the log's data structure (the Merkle tree) prevent the log from denying that misbehavior.
Certificate Transparency auditors
Auditors also act as clients to the log servers. Certificate Transparency auditors use partial information about a log to verify the log against other partial information they have.[1]: §8.3
Certificate Transparency log programs
Apple[16] and Google[13] have separate log programs with distinct policies and lists of trusted logs.
Root stores of Certificate Transparency logs
Certificate Transparency logs maintain their own root stores and only accept certificates that chain back to the trusted roots.[1] A number of misbehaving logs have been publishing inconsistent root stores in the past.[17]
History
In 2011, a reseller of the certificate authority
In March 2013, Google launched its first certificate transparency log.[20]
In June 2013,
In September 2013, DigiCert became the first certificate authority to implement Certificate Transparency.[21]
In 2015,
On March 23, 2018, Cloudflare announced its own CT log named Nimbus.[26]
In May 2019, certificate authority Let's Encrypt launched its own CT log called Oak. Since February 2020, it is included in approved log lists and is usable by all publicly-trusted certificate authorities.[27]
In December 2021,
In February 2022, Google published an update to their CT policy,[28] which removes the requirement for certificates to include a SCT from their own CT log service, matching all the requirements for certificates to those previously published by Apple.[29]
Signature Algorithms
In Certificate Transparency Version 2.0, a log must use one of the algorithms in the IANA registry "Signature Algorithms".[1]: 10.2.2 [30]
Tools for inspecting CT logs
- crt.sh by Sectigo
- Censys Search
- Cert Spotter by sslmate
- certstream.calidog.io
- ct.cloudflare.com - Merkle Town by Cloudflare
- Meta Certificate Transparency Monitoring by Meta
- Certificate Transparency Root Explorer
- EZMonitor by Keytos[31]
References
- ^ .
- ^ Solomon, Ben (8 August 2019). "Introducing Certificate Transparency Monitoring". Cloudflare. Archived from the original on 8 August 2019. Retrieved 9 August 2019.
Ah, Certificate Transparency (CT). CT solves the problem I just described by making all certificates public and easy to audit. When CAs issue certificates, they must submit certificates to at least two "public logs." This means that collectively, the logs carry important data about all trusted certificates on the Internet.
- ^ S2CID 52814744.
- ^ a b "How CT Works : Certificate Transparency". certificate.transparency.dev. Retrieved 2022-02-25.
- ^ "Certificate Transparency (CT) Logs". Let's Encrypt. Retrieved 2024-01-04.
- ^ "Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates" (PDF). CA/B Forum. Retrieved 4 January 2024.
- ^ Call, Ashley (2015-06-03). "Certificate Transparency: FAQs | DigiCert Blog". DigiCert. Retrieved 2021-04-13.
- ^ a b O'Brien, Devon (7 February 2018). "Certificate Transparency Enforcement in Google Chrome". Google Groups. Retrieved 18 December 2019.
- ^ This applies for certificates issued on or after 15 April 2022. For older certificates, other criteria apply.
- ^ "Chrome Certificate Transparency Policy". CertificateTransparency. Retrieved 2022-02-26.
- ^ "Certificate Transparency - Web security | MDN". developer.mozilla.org. Retrieved 2022-02-26.
- ^ "Apple's Certificate Transparency policy". Apple Support. 5 March 2021. Retrieved 2022-02-26.
- ^ a b "Chrome CT Log Policy". googlechrome.github.io. Retrieved 2021-10-14.
- S2CID 52034337.
- ^ "Scaling CT Logs: Temporal Sharding | DigiCert.com". www.digicert.com. Retrieved 2022-02-26.
- ^ "Apple's Certificate Transparency log program". apple.com. 28 January 2019. Retrieved 2021-10-14.
- )
- ^ Bright, Peter (August 30, 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. Retrieved 2018-02-10.
- ^ Laurie, Ben; Langley, Adam; Kasper, Emilia (2012-09-12). "Certificate Transparency (draft-laurie-pki-sunlight)". ietf.org. IETF. Retrieved 2023-05-28.
- ^ "Known Logs - Certificate Transparency". certificate-transparency.org. Retrieved 2015-12-31.
- ^ "DigiCert Announces Certificate Transparency Support". Dark Reading. 2013-09-24. Retrieved 2018-10-31.
- ^ Woodfield, Meggie (December 5, 2014). "Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome". DigiCert Blog. DigiCert.
- ^ Laurie, Ben (February 4, 2014). "Updated Certificate Transparency + Extended Validation plan". [email protected] (Mailing list). Archived from the original on 2014-03-30.
- Symantec. June 9, 2016. Archived from the originalon October 5, 2016. Retrieved September 22, 2016.
- ^ Sleevi, Ryan (October 28, 2015). "Sustaining Digital Certificate Security". Google Security Blog.
- ^ Sullivan, Nick (23 March 2018). "Introducing Certificate Transparency and Nimbus". cloudflare.com. Archived from the original on 23 March 2018. Retrieved 9 August 2019.
- ^ "Introducing Oak, a Free and Open Certificate Transparency Log - Let's Encrypt". letsencrypt.org. Retrieved 2021-04-13.
- ^ "Google CT Policy Update". Google Groups. Retrieved 2022-02-14.
- ^ "Apple's Certificate Transparency Policy". support.apple.com. 5 March 2021. Retrieved 2022-02-14.
- ^ "Signature Algorithms". Public Notary Transparency. IANA. Retrieved 2023-05-28.
- ^ "Monitors : Certificate Transparency". certificate.transparency.dev. Retrieved 2023-03-06.
External links
- Official website
- RFC 6962)
- crt.sh, a Certificate Transparency Log search engine
- Google Certificate Transparency Report
- Certificate Transparency Monitoring by Meta
- CT test on badssl.com