Jump to content

Certificate Transparency

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Dscheinder (talk | contribs) at 12:59, 11 July 2021. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Certificate Transparency (CT) is an Internet security standard and open source framework for monitoring and auditing digital certificates.[1] The standard creates a system of public logs that seek to eventually record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates.[2]

Certificate Transparency is described in an experimental RFC 6962.

As of 2021, Certificate Transparency is mandatory for all TLS certificates, but not other types of certificates.[3][4]

Background

In 2011, a reseller of the certificate authority Comodo was attacked and the certificate authority DigiNotar was compromised,[5] calling attention to existing flaws in the certificate authority ecosystem and accelerating work on various mechanisms to prevent or monitor unauthorized certificate issuance. Ben Laurie, Adam Langley and Emilia Kasper began work on an open source framework to combat these issues the same year. They submitted the first draft of the standard as an IETF Internet Draft in 2012 under the code-name "Sunlight".

Advantages

One of the problems with digital certificate management is that fraudulent certificates take a long time to be spotted, reported and revoked by the browser vendors. Certificate Transparency would help by making it impossible for a certificate to be issued for a domain without the domain owner knowing.

Certificate Transparency does not require side channel communication to validate certificates as do some competing technologies such as Online Certificate Status Protocol (OCSP) and Convergence. Certificate Transparency also operates without the need to trust a third party.

Certificate Transparency logs

Certificate Transparency depends on verifiable Certificate Transparency logs. A log appends new certificates to an ever-growing Merkle hash tree.[1]: Section 3  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]: Section 5.4 

History

An example of Certificate Transparency entry on Firefox 89

In March 2013, Google launched its first certificate transparency log.[6] In September 2013, DigiCert became the first certificate authority to implement Certificate Transparency.[7]

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

On March 23, 2018, Cloudflare announced its own CT log named Nimbus.[12]

In March 2018, "Certificate Transparency Version 2.0" draft was published but it did not become a standard and expired six months later.[13]

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.[14]

Signature Algorithms

Currently, a log must use NIST P-256 curve, or RSA signatures (using a key of at least 2048 bits).[1]:section 2.1.4

When Certificate Transparency Version 2.0 standard[15] will be published, the allowed algorithms will be NIST P-256, Deterministic ECDSA, or Ed25519.

Tools for inspecting CT logs

References

  1. ^ a b c d Laurie, Ben; Langley, Adam; Kasper, Emilia (June 2013). Certificate Transparency. IETF. doi:10.17487/RFC6962. ISSN 2070-1721. RFC 6962.
  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. ^ Call, Ashley (2015-06-03). "Certificate Transparency: FAQs | DigiCert Blog". DigiCert. Retrieved 2021-04-13.
  4. ^ a b O'Brien, Devon (7 February 2018). "Certificate Transparency Enforcement in Google Chrome". Google Groups. Retrieved 18 December 2019.
  5. ^ Bright, Peter (August 30, 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. Retrieved 2018-02-10.
  6. ^ "Known Logs - Certificate Transparency". certificate-transparency.org. Retrieved 2015-12-31.
  7. ^ "DigiCert Announces Certificate Transparency Support". Dark Reading. 2013-09-24. Retrieved 2018-10-31.
  8. ^ Woodfield, Meggie (December 5, 2014). "Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome". DigiCert Blog. DigiCert.
  9. ^ Laurie, Ben (February 4, 2014). "Updated Certificate Transparency + Extended Validation plan". public@cabforum.org (Mailing list). Archived from the original on 2014-03-30.
  10. ^ "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.
  11. ^ Sleevi, Ryan (October 28, 2015). "Sustaining Digital Certificate Security". Google Security Blog.
  12. ^ Sullivan, Nick (23 March 2018). "Introducing Certificate Transparency and Nimbus". Cloudflare. Archived from the original on 23 March 2018. Retrieved 9 August 2019.
  13. ^ Laurie, B. (2018-03-05). "Certificate Transparency Version 2.0". tools.ietf.org. Retrieved 2021-04-13.
  14. ^ "Introducing Oak, a Free and Open Certificate Transparency Log - Let's Encrypt". letsencrypt.org. Retrieved 2021-04-13.
  15. ^ "draft-ietf-trans-rfc6962-bis-39 - Certificate Transparency Version 2.0". datatracker.ietf.org. Retrieved 2021-07-11.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Certificate_Transparency&oldid=1033076979"