Certificate Transparency
{{Short description|System of public logs of digital certificates}}
{{Technical|date=August 2023}}
Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates.{{Cite IETF |title=Certificate Transparency|rfc=6962|date=June 2013}} When an internet user interacts with a website, a trusted third party is needed for assurance that the website is legitimate and that the website's encryption key is valid. This third party, called a certificate authority (CA), will issue a certificate for the website that the user's browser can validate. The security of encrypted internet traffic depends on the trust that certificates are only given out by the certificate authority and that the certificate authority has not been compromised.
Certificate Transparency makes public all issued certificates in the form of a distributed ledger, giving website owners and auditors the ability to detect and expose inappropriately issued certificates.
Work on Certificate Transparency first began in 2011 after the certificate authority DigiNotar became compromised and started issuing malicious certificates. Google engineers submitted a draft to the Internet Engineering Task Force (IETF) in 2012. This effort resulted in IETF {{IETF RFC|6962}}, a standard defining a system of public logs to record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates.{{Cite web | url = https://blog.cloudflare.com/introducing-certificate-transparency-monitoring/ | title = Introducing Certificate Transparency Monitoring | access-date = 9 August 2019 | first = Ben | last = Solomon | date = 8 August 2019 | website = Cloudflare | quote = 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. | archive-url = https://web.archive.org/web/20190808221646/https://blog.cloudflare.com/introducing-certificate-transparency-monitoring/ | archive-date = 8 August 2019 | df = dmy-all }}
Technical overview
The certificate transparency system consists of a system of append-only certificate logs. Logs are operated by many parties, including browser vendors and certificate authorities.{{Cite book|last1=Scheitle|first1=Quirin|last2=Gasser|first2=Oliver|last3=Nolte|first3=Theodor|last4=Amann|first4=Johanna|last5=Brent|first5=Lexi|last6=Carle|first6=Georg|last7=Holz|first7=Ralph|last8=Schmidt|first8=Thomas C.|last9=Wählisch|first9=Matthias|title=Proceedings of the Internet Measurement Conference 2018 |chapter=The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem |date=2018-10-31|language=en|location=Boston MA USA|publisher=ACM|pages=343–349|doi=10.1145/3278532.3278562|isbn=978-1-4503-5619-0|s2cid=52814744 |doi-access=free}} Certificates that support certificate transparency must include one or more signed certificate timestamps (SCTs), which is a promise from a log operator to include the certificate in their log within a maximum merge delay (MMD).{{Cite web|title=How CT Works : Certificate Transparency|url=https://certificate.transparency.dev/howctworks/|access-date=2022-02-25|website=certificate.transparency.dev|archive-date=2022-02-25|archive-url=https://web.archive.org/web/20220225233202/https://certificate.transparency.dev/howctworks/|url-status=live}} At some point within the maximum merge delay, the log operator adds the certificate to their log. Each entry in a log references the hash of a previous one, forming a Merkle tree. The signed tree head (STH) references the current root of the Merkle tree.
=Logging procedure=
Although anyone can submit a certificate to a CT log, this task is commonly carried out by a CA as follows:{{Cite web|title=Certificate Transparency (CT) Logs|date=25 September 2023 |url=https://letsencrypt.org/docs/ct-logs/|publisher=Let's Encrypt|access-date=2024-01-04|archive-date=2024-01-04|archive-url=https://web.archive.org/web/20240104055331/https://letsencrypt.org/docs/ct-logs/|url-status=live}}
- An applicant, "The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate",{{cite web|url=https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.1.pdf|title=Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates|publisher=CA/B Forum|access-date=4 January 2024|archive-date=4 January 2024|archive-url=https://web.archive.org/web/20240104220954/https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.1.pdf|url-status=live}} requests a certificate from a CA.
- The CA issues a special precertificate, a certificate which carries a poison extension signaling that it should not be accepted by user agents.
- The CA sends the precertificate to logs.
- Logs return corresponding SCTs to the CA.
- The CA attaches SCTs collected from logs as an X.509 extension to the final certificate and provides it to the applicant.
Finally, the 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 [https://crt.sh/?caid=183283 crt.sh profile page] under 'issued certificates' section), whereas Google GTS CA 2A1 does not (see [https://crt.sh/?caid=180750 crt.sh profile page]).
=Mandatory certificate transparency=
Some browsers require Transport Layer Security (TLS) certificates to have proof of being logged with certificate transparency,{{Cite web|last=Call|first=Ashley|date=2015-06-03|title=Certificate Transparency: FAQs {{!}} DigiCert Blog|url=https://www.digicert.com/dc/blog/certificate-transparency-faqs/|access-date=2021-04-13|website=DigiCert|language=en-US|archive-date=2022-05-20|archive-url=https://web.archive.org/web/20220520141427/https://www.digicert.com/dc/blog/certificate-transparency-faqs/|url-status=dead}} either through SCTs embedded into the certificate, an extension during the TLS handshake, or through OCSP:
class="wikitable sortable"
|+ |
Browser
! Current SCT requirements ! Current OCSP/TLS extension requirements |
---|
Chrome/Chromium
| {{yes|
| {{yes|
}} |
Firefox
| {{partial| {{Cite web|title=Certificate Transparency - Web security {{!}} MDN|url=https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency|access-date=2025-02-24|website=developer.mozilla.org|date=27 January 2025 |language=en-US}} {{Cite web |title=Certificate Transparency is now enforced in Firefox on desktop platforms starting with version 135 |url=https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/OagRKpVirsA/m/Q4c89XG-EAAJ?pli=1 |access-date=2025-02-24 |website=dev-security-policy@mozilla.org}} (released 2025-02-04) }} | {{no|None}}{{Update inline|date=February 2025|?=yes}} |
Safari
| {{yes|
| {{yes|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 and certificates with an expiration date in a particular time period (usually a calendar year).{{Cite book |last1=Tomescu |first1=Alin |last2=Bhupatiraju |first2=Vivek |last3=Papadopoulos |first3=Dimitrios |last4=Papamanthou |first4=Charalampos |last5=Triandopoulos |first5=Nikos |last6=Devadas |first6=Srinivas |title=Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security |chapter=Transparency Logs via Append-Only Authenticated Dictionaries |date=2019-11-06 |language=en |location=London United Kingdom |publisher=ACM |pages=1299–1316 |doi=10.1145/3319535.3345652 |isbn=978-1-4503-6747-9|s2cid=52034337 |doi-access=free }}{{Cite web |title=Scaling CT Logs: Temporal Sharding {{!}} DigiCert.com |url=https://www.digicert.com/blog/scaling-certificate-transparency-logs-temporal-sharding |access-date=2022-02-26 |website=www.digicert.com |language=en-US |archive-date=2022-02-26 |archive-url=https://web.archive.org/web/20220226194718/https://www.digicert.com/blog/scaling-certificate-transparency-logs-temporal-sharding |url-status=live }} 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. The main advantage with Certificate Transparency is the ability for cyber security teams to defend companies and organisations by monitoring for suspicious domains registering certificates. The new certificates for these suspicious domains may have similar names to other legitimate domains and are designed to be used to support malicious activities such as phishing attacks. Certificate Transparency puts cyber security teams in control and enables them to issue domain take down orders for suspicious domains and allows them to apply cyber security controls on web proxies and email gateways for immediate protection. {{Cite web |url=https://www.itsecuritylocksmith.co.uk/certificate-transparency/ |title=Certificate transparency and how cybersecurity teams can use it? |date=4 June 2024 |access-date=2025-01-10 |archive-date=2025-01-10 |archive-url=https://web.archive.org/web/20250110142444/https://www.itsecuritylocksmith.co.uk/certificate-transparency/ |url-status=live }}
=Side Effects=
Domain names that are used on internal networks and have certificates issued by certificate authorities become publicly searchable as their certificates are added to CT logs.
=Certificate Transparency logs=
Certificate Transparency depends on verifiable Certificate Transparency logs. A log appends new certificates to an ever-growing Merkle hash tree.{{rp |at=§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=
=Certificate Transparency log programs=
Apple{{Cite web|title=Apple's Certificate Transparency log program.|url=https://support.apple.com/en-us/HT209255|access-date=2021-10-14|website=apple.com|date=28 January 2019|archive-date=2021-10-27|archive-url=https://web.archive.org/web/20211027183407/https://support.apple.com/en-us/HT209255|url-status=live}} and Google{{Cite web|title=Chrome CT Log Policy.|url=https://googlechrome.github.io/CertificateTransparency/log_policy.html|access-date=2021-10-14|website=googlechrome.github.io|archive-date=2021-10-26|archive-url=https://web.archive.org/web/20211026232013/https://googlechrome.github.io/CertificateTransparency/log_policy.html|url-status=live}} 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. A number of misbehaving logs have been publishing inconsistent root stores in the past.{{cite book|author1=Korzhitskii, Nikita|author2=Carlsson, Niklas|title=Characterizing the root landscape of Certificate Transparency logs|publication-place=In proceedings of 2020 IFIP Networking Conference (Networking)|year=2020 |arxiv=2001.04319 }}
History
File:Signed Certificate Transparency on Firefox 89 screenshot.png
In 2011, a reseller of the certificate authority Comodo was attacked and the certificate authority DigiNotar was compromised,{{Cite news|last=Bright|first=Peter|date=August 30, 2011|title=Another fraudulent certificate raises the same old questions about certificate authorities|language=en-us|work=Ars Technica|url=https://arstechnica.com/information-technology/2011/08/earlier-this-year-an-iranian/|access-date=2018-02-10|archive-date=2018-02-10|archive-url=https://web.archive.org/web/20180210180047/https://arstechnica.com/information-technology/2011/08/earlier-this-year-an-iranian/|url-status=live}} demonstrating existing flaws in the certificate authority ecosystem and prompting work on various mechanisms to prevent or monitor unauthorized certificate issuance. Google employees Ben Laurie, Adam Langley and Emilia Kasper began work on an open source framework for detecting mis-issued certificates the same year. In 2012, they submitted the first draft of the standard to IETF under the code-name "Sunlight".{{Cite journal |last1=Laurie |first1=Ben |last2=Langley |first2=Adam |last3=Kasper |first3=Emilia |date=2012-09-12 |title=Certificate Transparency (draft-laurie-pki-sunlight) |url=https://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/00/ |access-date=2023-05-28 |website=ietf.org |publisher=IETF |archive-date=2023-05-29 |archive-url=https://web.archive.org/web/20230529002411/https://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/00/ |url-status=live }}
In March 2013, Google launched its first certificate transparency log.{{cite web |url=http://www.certificate-transparency.org/known-logs |title=Known Logs - Certificate Transparency |website=certificate-transparency.org |access-date=2015-12-31 |archive-date=2016-12-16 |archive-url=https://web.archive.org/web/20161216085124/http://www.certificate-transparency.org/known-logs |url-status=live }}
In June 2013, {{IETF RFC|6962}} "Certificate Transparency" was published, based on the 2012 draft.
In September 2013, DigiCert became the first certificate authority to implement Certificate Transparency.{{cite web |url=https://www.darkreading.com/risk/digicert-announces-certificate-transparency-support/d/d-id/1140538 |title=DigiCert Announces Certificate Transparency Support |publisher=Dark Reading |date=2013-09-24 |accessdate=2018-10-31 |archive-date=2018-11-01 |archive-url=https://web.archive.org/web/20181101055222/https://www.darkreading.com/risk/digicert-announces-certificate-transparency-support/d/d-id/1140538 |url-status=live }}
In 2015, Google Chrome began requiring Certificate Transparency for newly issued Extended Validation Certificates.{{cite web |url=https://blog.digicert.com/certificate-transparency-required-ev-certificates-show-green-address-bar-chrome/ |title=Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome |date=December 5, 2014 |last=Woodfield |first=Meggie |work=DigiCert Blog |publisher=DigiCert |access-date=December 31, 2015 |archive-date=October 13, 2016 |archive-url=https://web.archive.org/web/20161013173422/https://blog.digicert.com/certificate-transparency-required-ev-certificates-show-green-address-bar-chrome/ |url-status=live }}{{cite mailing list|url=https://cabforum.org/pipermail/public/2014-February/002840.html |title=Updated Certificate Transparency + Extended Validation plan |date=February 4, 2014 |last=Laurie|first=Ben |mailing-list=public@cabforum.org
|archive-url=https://web.archive.org/web/20140330191951/https://cabforum.org/pipermail/public/2014-February/002840.html |archive-date=2014-03-30 |url-status=live}} It began requiring Certificate Transparency for all certificates newly issued by Symantec from June 1, 2016, after they were found to have issued 187 certificates without the domain owners' knowledge.{{cite web |url=https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=INFO3663 |title=Symantec Certificate Transparency (CT) for certificates issued before June 1, 2016 |date=June 9, 2016 |work=Symantec Knowledge Center |publisher=Symantec |access-date=September 22, 2016 |archive-url=https://web.archive.org/web/20161005230125/https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=INFO3663 |archive-date=October 5, 2016 |url-status=dead }}{{cite web |url=https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html |title=Sustaining Digital Certificate Security |date=October 28, 2015 |work=Google Security Blog |last=Sleevi |first=Ryan |access-date=September 22, 2016 |archive-date=December 7, 2016 |archive-url=https://web.archive.org/web/20161207170146/https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html |url-status=live }} Since April 2018, this requirement has been extended to all certificates.{{cite web |last1=O'Brien |first1=Devon |title=Certificate Transparency Enforcement in Google Chrome |url=https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ |publisher=Google Groups |accessdate=18 December 2019 |date=7 February 2018 |archive-date=23 May 2013 |archive-url=https://web.archive.org/web/20130523081122/http://groups.google.com/a/chromium.org/group/chromium-os-dev/browse_thread/thread/337cca9a0da59ad6/9354a38894da5df5#!msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ |url-status=live }}
On March 23, 2018, Cloudflare announced its own CT log named Nimbus.{{Cite web|url=https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/| title=Introducing Certificate Transparency and Nimbus| access-date=9 August 2019| first=Nick| last=Sullivan| date=23 March 2018| website=cloudflare.com| archive-url=https://web.archive.org/web/20180323160208/https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/ |archive-date=23 March 2018| url-status=live| df=dmy-all}}
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.{{Cite web|title=Introducing Oak, a Free and Open Certificate Transparency Log - Let's Encrypt|url=https://letsencrypt.org/2019/05/15/introducing-oak-ct-log.html|access-date=2021-04-13|website=letsencrypt.org|date=15 May 2019 |archive-date=2021-04-13|archive-url=https://web.archive.org/web/20210413175631/https://letsencrypt.org/2019/05/15/introducing-oak-ct-log.html|url-status=live}}
In December 2021, {{IETF RFC|9162}} "Certificate Transparency Version 2.0" was published.{{Cite IETF |title=Certificate Transparency Version 2.0|rfc=9162 |date=December 2021}} Version 2.0 includes major changes to the required structure of the log certificate, as well as support for Ed25519 as a signature algorithm of SCTs and support for including certificate inclusion proofs with the SCT. However, it has not seen industry adoption and is considered dead on arrival.{{Cite web|url=https://community.letsencrypt.org/t/certificate-transparency-versions-and-status-of-ctv2/218492/4 | title = Certificate Transparency versions and status of CTv2 | access-date = 12 March 2025 | first = Matthew | last = McPherrin | date = May 2024 | website = Let's Encrypt | quote = I don’t believe there are any implementations of ct v2, and nobody runs any logs. Let’s Encrypt has no plans to run ctv2 logs. Sunlight is an evolution based on v1. It does seem like ctv2 is DOA.|archive-url=https://web.archive.org/web/20250312145813/https://community.letsencrypt.org/t/certificate-transparency-versions-and-status-of-ctv2/218492/4|archive-date=12 March 2025|url-status=live}}
In February 2022, Google published an update to their CT policy,{{Cite web|title=Google CT Policy Update|url=https://groups.google.com/a/chromium.org/g/ct-policy/c/507lPdbbwSk|access-date=2022-02-14|website=Google Groups|archive-date=2022-02-10|archive-url=https://web.archive.org/web/20220210235435/https://groups.google.com/a/chromium.org/g/ct-policy/c/507lPdbbwSk|url-status=live}} 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.{{Cite web|title=Apple's Certificate Transparency Policy|url=https://support.apple.com/en-us/HT205280|access-date=2022-02-14|website=support.apple.com|date=5 March 2021|archive-date=2022-02-14|archive-url=https://web.archive.org/web/20220214150730/https://support.apple.com/en-us/HT205280|url-status=live}}
In February 2025, Mozilla Firefox desktop version 135 began requiring Certificate Transparency for all certificates issued by a certificate authority in Mozilla's Root CA Program.{{Cite web |author=Mozilla |url=https://www.mozilla.org/en-US/firefox/135.0/releasenotes/ |title=Firefox 135.0, See All New Features, Updates and Fixes |website=Mozilla.org |accessdate=2025-02-05 |quote=Firefox now enforces certificate transparency, requiring web servers to provide sufficient proof that their certificates were publicly disclosed before they will be trusted. This only affects servers using certificates issued by a certificate authority in Mozilla's Root CA Program.}}{{Cite web |author=Mozilla |url=https://en.wikipedia.org/wiki/Certificate_Transparency |title=Certificate Transparency - Security on the web |website=MDN |accessdate=2025-02-05 |quote=Firefox desktop from version 135 requires CT log inclusion for all certificates issued by certificate authorities in Mozilla's Root CA Program. Firefox for Android does not currently require CT log inclusion.}}
Signature algorithms
In Certificate Transparency Version 2.0, a log must use one of the algorithms in the IANA registry "Signature Algorithms".{{rp |at=10.2.2}}{{Cite web |title=Signature Algorithms |url=https://www.iana.org/assignments/trans/trans.xhtml#trans-signature-algorithms |access-date=2023-05-28 |website=Public Notary Transparency |publisher=IANA}}
Tools for inspecting CT logs
- [https://www.merklemap.com/ Merklemap]
- [https://crt.sh crt.sh] by Sectigo
- [https://search.censys.io/search?resource=certificates&q= Censys Search]
- [https://sslmate.com/certspotter/ Cert Spotter by sslmate]
- [https://certstream.calidog.io/ certstream.calidog.io]
- [https://ct.cloudflare.com/ ct.cloudflare.com] - Merkle Town by Cloudflare
- [https://developers.facebook.com/tools/ct/search/ Meta] Certificate Transparency Monitoring by Meta
- [https://nikita-kun.github.io/certificate-transparency-root-explorer/ Certificate Transparency Root Explorer]
- [https://www.keytos.io/SSL-Monitoring.html EZMonitor] by [https://www.keytos.io/ Keytos]{{Cite web |title=Monitors : Certificate Transparency |url=https://certificate.transparency.dev/monitors/ |access-date=2023-03-06 |website=certificate.transparency.dev |archive-date=2023-02-27 |archive-url=https://web.archive.org/web/20230227151232/https://certificate.transparency.dev/monitors/ |url-status=live }}
See also
References
External links
- {{Official website|https://www.certificate-transparency.org/}}
- {{IETF RFC|9162}} Certificate Transparency Version 2.0 (which obsoleted previous {{IETF RFC|6962}})
- [https://crt.sh/ crt.sh], a Certificate Transparency Log search engine
- [https://transparencyreport.google.com/https/certificates Google Certificate Transparency Report]
- [https://developers.facebook.com/tools/ct/ Certificate Transparency Monitoring by Meta]
- [https://no-sct.badssl.com/ CT test on badssl.com]
{{SSL/TLS}}