Certificate Transparency

Last updated

Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates. [1] 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.

Contents

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 RFC   9162, 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. [2]

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. [3] 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). [4] [3] 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: [4] [5]

  1. An applicant, "The natural person or Legal Entity that applies for (or seeks renewal of ) a Certificate", [6] requests a certificate from a CA.
  2. CA issues a special precertificate, a certificate which carries a poison extension signalling that it shouldn't be accepted by user agents.
  3. CA sends the precertificate to logs
  4. Logs return corresponding SCTs to the CA
  5. 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 Transport Layer Security (TLS) certificates to have proof of being logged with certificate transparency, [7] [8] either through SCTs embedded into the certificate, an extension during the TLS handshake, or through OCSP:

BrowserCurrent SCT requirementsCurrent OCSP/TLS extension requirements
Chrome/Chromium
  • One SCT from a currently approved log
  • Duration ≤ 180 days: 2 SCTs from once-approved logs
  • Duration > 180 days: 3 SCTs from once-approved logs [9] [10]
  • 1 SCT from a current Google log
  • 1 SCT from a current non-Google log
Firefox None [11] None
Safari
  • One SCT from a currently approved log
  • Duration ≤ 180 days: 2 SCTs from once-approved logs
  • Duration > 180 days: 3 SCTs from once-approved logs [12]
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). [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.

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. [1] : §4  To be seen as behaving correctly, a log must:

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

An example of Certificate Transparency entry on Firefox 89 Signed Certificate Transparency on Firefox 89 screenshot.png
An example of Certificate Transparency entry on Firefox 89

In 2011, a reseller of the certificate authority Comodo was attacked and the certificate authority DigiNotar was compromised, [18] 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". [19]

In March 2013, Google launched its first certificate transparency log. [20]

In June 2013, RFC   6962 "Certificate Transparency" was published, based on the 2012 draft.

In September 2013, DigiCert became the first certificate authority to implement Certificate Transparency. [21]

In 2015, Google Chrome began requiring Certificate Transparency for newly issued Extended Validation Certificates. [22] [23] 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. [24] [25] Since April 2018, this requirement has been extended to all certificates. [8]

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, RFC   9162 "Certificate Transparency Version 2.0" was published. [1] 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.

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

See also

Related Research Articles

X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 was first approved in 1988. The directory services were developed to support requirements of X.400 electronic mail exchange and name lookup. The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) were partners in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO/IEC identification.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network, such as the Internet. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

<span class="mw-page-title-main">Root certificate</span> Certificate identifying a root authority

In cryptography and computer security, a root certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed and form the basis of an X.509-based public key infrastructure (PKI). Either it has matched Authority Key Identifier with Subject Key Identifier, in some cases there is no Authority Key identifier, then Issuer string should match with Subject string. For instance, the PKIs supporting HTTPS for secure web browsing and electronic signature schemes depend on a set of root certificates.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Thawte Consulting is a certificate authority (CA) for X.509 certificates. Thawte was founded in 1995 by Mark Shuttleworth in South Africa. As of December 30, 2016, its then-parent company, Symantec Group, was collectively the third largest public CA on the Internet with 17.2% market share.

GeoTrust is a digital certificate provider. The GeoTrust brand was bought by Symantec from Verisign in 2010, but agreed to sell the certificate business in August 2017 to private equity and growth capital firm Thoma Bravo LLC. GeoTrust was the first certificate authority to use the domain-validated certificate method which accounts for 70 percent of all SSL certificates on the Internet. By 2006, GeoTrust was the 2nd largest certificate authority in the world with 26.7 percent market share according to independent survey company Netcraft.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

<span class="mw-page-title-main">DigiCert</span> Internet security company

DigiCert, Inc. is a digital security company headquartered in Lehi, Utah. DigiCert provides public key infrastructure (PKI) and validation required for issuing digital certificates or TLS/SSL certificates, acting as a certificate authority (CA) and trusted third party.

The Certification Authority Browser Forum, also known as the CA/Browser Forum, is a voluntary consortium of certification authorities, vendors of Internet browser and secure email software, operating systems, and other PKI-enabled applications that promulgates industry guidelines governing the issuance and management of X.509 v.3 digital certificates that chain to a trust anchor embedded in such applications. Its guidelines cover certificates used for the SSL/TLS protocol and code signing, as well as system and network security of certificate authorities.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

<span class="mw-page-title-main">Certificate Authority Security Council</span> Organization

The Certificate Authority Security Council (CASC) is a multi-vendor industry advocacy group created to conduct research, promote Internet security standards and educate the public on Internet security issues.

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

Trustico is a dedicated SSL certificate provider, They are headquartered in the United Kingdom.

In 2015, the government of Kazakhstan created a root certificate which could have enabled a man-in-the-middle attack on HTTPS traffic from Internet users in Kazakhstan. The government described it as a "national security certificate". If installed on users' devices, the certificate would have allowed the Kazakh government to intercept, decrypt, and re-encrypt any traffic passing through systems it controlled.

References

  1. 1 2 3 4 5 6 Certificate Transparency Version 2.0. December 2021. doi: 10.17487/RFC9162 . RFC 9162.
  2. ↑ 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.
  3. 1 2 Scheitle, Quirin; Gasser, Oliver; Nolte, Theodor; Amann, Johanna; Brent, Lexi; Carle, Georg; Holz, Ralph; Schmidt, Thomas C.; Wählisch, Matthias (2018-10-31). "The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem". Proceedings of the Internet Measurement Conference 2018. Boston MA USA: ACM. pp. 343–349. doi: 10.1145/3278532.3278562 . ISBN   978-1-4503-5619-0. S2CID   52814744.
  4. 1 2 "How CT Works : Certificate Transparency". certificate.transparency.dev. Retrieved 2022-02-25.
  5. ↑ "Certificate Transparency (CT) Logs". Let's Encrypt. Retrieved 2024-01-04.
  6. ↑ "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" (PDF). CA/B Forum. Retrieved 4 January 2024.
  7. ↑ Call, Ashley (2015-06-03). "Certificate Transparency: FAQs | DigiCert Blog". DigiCert. Retrieved 2021-04-13.
  8. 1 2 O'Brien, Devon (7 February 2018). "Certificate Transparency Enforcement in Google Chrome". Google Groups. Retrieved 18 December 2019.
  9. ↑ This applies for certificates issued on or after 15 April 2022. For older certificates, other criteria apply.
  10. ↑ "Chrome Certificate Transparency Policy". CertificateTransparency. Retrieved 2022-02-26.
  11. ↑ "Certificate Transparency - Web security | MDN". developer.mozilla.org. Retrieved 2022-02-26.
  12. ↑ "Apple's Certificate Transparency policy". Apple Support. 5 March 2021. Retrieved 2022-02-26.
  13. 1 2 "Chrome CT Log Policy". googlechrome.github.io. Retrieved 2021-10-14.
  14. ↑ Tomescu, Alin; Bhupatiraju, Vivek; Papadopoulos, Dimitrios; Papamanthou, Charalampos; Triandopoulos, Nikos; Devadas, Srinivas (2019-11-06). "Transparency Logs via Append-Only Authenticated Dictionaries". Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. London United Kingdom: ACM. pp. 1299–1316. doi: 10.1145/3319535.3345652 . ISBN   978-1-4503-6747-9. S2CID   52034337.
  15. ↑ "Scaling CT Logs: Temporal Sharding | DigiCert.com". www.digicert.com. Retrieved 2022-02-26.
  16. ↑ "Apple's Certificate Transparency log program". apple.com. 28 January 2019. Retrieved 2021-10-14.
  17. ↑ Korzhitskii, Nikita; Carlsson, Niklas (2020). Characterizing the root landscape of Certificate Transparency logs. arXiv: 2001.04319 .{{cite book}}: |work= ignored (help)
  18. ↑ Bright, Peter (August 30, 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica . Retrieved 2018-02-10.
  19. ↑ Laurie, Ben; Langley, Adam; Kasper, Emilia (2012-09-12). "Certificate Transparency (draft-laurie-pki-sunlight)". ietf.org. IETF . Retrieved 2023-05-28.
  20. ↑ "Known Logs - Certificate Transparency". certificate-transparency.org. Retrieved 2015-12-31.
  21. ↑ "DigiCert Announces Certificate Transparency Support". Dark Reading. 2013-09-24. Retrieved 2018-10-31.
  22. ↑ Woodfield, Meggie (December 5, 2014). "Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome". DigiCert Blog. DigiCert.
  23. ↑ Laurie, Ben (February 4, 2014). "Updated Certificate Transparency + Extended Validation plan". public@cabforum.org (Mailing list). Archived from the original on 2014-03-30.
  24. ↑ "Symantec Certificate Transparency (CT) for certificates issued before June 1, 2016". Symantec Knowledge Center. Symantec. June 9, 2016. Archived from the original on October 5, 2016. Retrieved September 22, 2016.
  25. ↑ Sleevi, Ryan (October 28, 2015). "Sustaining Digital Certificate Security". Google Security Blog.
  26. ↑ Sullivan, Nick (23 March 2018). "Introducing Certificate Transparency and Nimbus". cloudflare.com. Archived from the original on 23 March 2018. Retrieved 9 August 2019.
  27. ↑ "Introducing Oak, a Free and Open Certificate Transparency Log - Let's Encrypt". letsencrypt.org. Retrieved 2021-04-13.
  28. ↑ "Google CT Policy Update". Google Groups. Retrieved 2022-02-14.
  29. ↑ "Apple's Certificate Transparency Policy". support.apple.com. 5 March 2021. Retrieved 2022-02-14.
  30. ↑ "Signature Algorithms". Public Notary Transparency. IANA . Retrieved 2023-05-28.
  31. ↑ "Monitors : Certificate Transparency". certificate.transparency.dev. Retrieved 2023-03-06.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.