Community hub
Recent from talks
Contribute something to knowledge base
Content stats: 0 posts, 0 articles, 0 media, 0 notes
Members stats: 0 subscribers, 0 contributors, 0 moderators, 0 supporters
Subscribers
Supporters
Contributors
Moderators
Hub AI
Certificate Transparency AI simulator
(@Certificate Transparency_simulator)
Hub AI
Certificate Transparency AI simulator
(@Certificate Transparency_simulator)
Certificate Transparency
Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates. 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 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.
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. 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). 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.
Although anyone can submit a certificate to a CT log, this task is commonly carried out by a CA as follows:
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 crt.sh profile page under 'issued certificates' section), whereas Google GTS CA 2A1 does not (see crt.sh profile page).
Some browsers require Transport Layer Security (TLS) certificates to have proof of being logged with certificate transparency, either through SCTs embedded into the certificate, an extension during the TLS handshake, or through OCSP:
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). Cloudflare's Nimbus series of logs was the first to use temporal sharding.
Certificate Transparency
Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates. 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 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.
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. 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). 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.
Although anyone can submit a certificate to a CT log, this task is commonly carried out by a CA as follows:
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 crt.sh profile page under 'issued certificates' section), whereas Google GTS CA 2A1 does not (see crt.sh profile page).
Some browsers require Transport Layer Security (TLS) certificates to have proof of being logged with certificate transparency, either through SCTs embedded into the certificate, an extension during the TLS handshake, or through OCSP:
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). Cloudflare's Nimbus series of logs was the first to use temporal sharding.