How Certificate Transparency works

Certificate Transparency

• How CT works
• Actors
• Our story

• GitHub

How CT works

How CT fits into the wider Web PKI ecosystem

Contents:

1. Certificate Transparency: an ecosystem
2. Certificate Transparency: step by step
3. How Certificate Transparency fits in Web Public Key Infrastructure

Certificate Transparency: an ecosystem

Certificates are deposited in public, transparent logs

Certificate logs are append-only ledgers of certificates. Because they're distributed and independent, anyone can query them to see what certificates have been included and when. Because they're append-only, they are verifiable by Monitors. Organisations and individuals with the technical skills and capacity can run a log.

User agents - browsers like Chrome and Safari - help enforce Certificate Transparency.

Check out the documentation on Github

Logs are cryptographically monitored

Monitors cryptographically check which certificates have been included in logs.

If you subscribe to a CT monitor for your domain, you get updates when precertificates and certificates for those domains are included in any of the logs checked by that monitor. Monitors can be set up and run by anyone

See the list of current monitors

Certificate Transparency: step by step

1. 1Website owner requests a certificate from the Certificate Authority (CA)A certificate ties together a domain and a public key. Certificate Transparency works with Web PKI/SSL certificate system, providing transparency and verification. The append-only log is tamper-proof, the User agent checks that logs are cryptographically consistent, and the Certificate Authority’s monitors will check for suspicious logs.
2. 2CA issues a precertificateA CA receives a request for a certificate from a domain owner. It checks that the domain owner has the right to request the certificate, and creates a precertificate, which ties the domain to a public key. A precertificate contains all the information a certificate does. It also has a poison extension so that user agents won’t accept it. Precertificates help break a deadlock in CT. Before a CA can log a certificate, the certificate needs an SCT (Signed Certificate Timestamp). But for the certificate to get an SCT, it needs to have been submitted to a log.
3. 3CA sends precertificates to logsAnyone can submit a certificate to a log, but most of them are submitted by CAs. When a CA submits one of these to a log, the log responds with a signed certificate timestamp (SCT). This is a promise to add the certificate to the log within a time period called the Maximum Merge Delay (MMD).
4. 4Precertificates are added to the logsLogs maintain a record of certificates. They use a special cryptographic mechanism, a Merkle tree, to allow public audits. Logs are:Append-only. Certificates can only be added to a log, not deleted, modified, or retroactively inserted.Cryptographically assured. They use Merkle trees which prevent tampering and misbehaviour.Publicly auditable. Anyone can query a log and verify that it’s well behaved, or verify a SSL certificate or precertificate has been legitimately appended to the log.Merkle trees are simple binary trees, made up of leaves and nodes. In CT, leaves are the hashes of individual certificates that have been appended to the log. Nodes are the hashes of paired child leaves or paired child nodes. The root hash, from which all nodes and leaves stem, is also a Merkle tree. When the log server signs the root Merkle tree it creates a Signed Tree Head (STH). Periodically, a log appends all the new certificates to the log. It creates a separate Merkle tree hash with the new certificates. It then combines this Merkle tree with the old Merkle tree to form a new Merkle tree. The new Merkle tree hash is then signed to create a new Signed Tree Head.
5. 5Logs return SCTs to the CAEach log immediately returns an SCT to the CA, with a commitment to include the certificate within the Maximum Merge Delay. The MMD is usually 24 hours: this timespan is designed to give log operators the time to fix anything that’s gone wrong before they are excluded from the list of approved logs. The MMD also helps ensure logs don’t block the issuance or use of certificates.CAs attach SCTs to a certificate using an X.509v3 extension. They sign the certificate and deliver the certificate to the server operator. (There are also two other, less common, ways of doing this: OCSP stapling and TLS extension.) CT doesn’t require server modification, so server operators can manage SSL certificates the way they always have.
6. 6CAs send the certificate to the domain ownerThe SCTs accompany the certificate throughout its lifetime. A server must deliver the SCT with the certificate during a TLS handshake. (A TLS handshake is when two sides of an encrypted communication verify each other and agree which encryption algorithms and keys to use. Here, that process begins when a user goes to an HTTPS website, and the web server responds to the HTTPS request.)
7. 7Browsers and user agents help keep the web secureSome browsers, like Chrome and Safari, help enforce CT.Both the number of logs, and the selection of logs a CA chooses to log, is determined by user agent policy. Both Safari and Chrome user agents require at least 2 SCTs, depending on certificate lifetimes.
8. 8Logs are cryptographically monitoredMonitors are publicly run servers. They periodically contact all log servers and watch for suspicious certificates. Monitors work with website operators to help them understand if an unauthorized certificate has been issued for a domain. They can watch for certificates that have unusual extensions or permissions, such as certificates that have CA capabilities. Monitors can prove, efficiently and quickly, that all certificates have been consistently appended to the log. They can also prove that a particular certificate has been appended to the log.For a monitor to check the consistency of a particular log, it computes a consistency proof itself and then uses this to verify the consistency of the log. A consistent later version includes everything in the earlier version, and following the entries from the older version.If a monitor ever needs to verify that a particular certificate exists in a log, it can compute an audit proof itself and use it to verify the presence of that certificate.Some monitors are run by companies and organizations. Others will be run as subscription services for domain owners and certificate authorities. Individuals can also run their own monitors.

How Certificate Transparency fits in Web Public Key Infrastructure

What is Web PKI?

CT sits within a wider ecosystem, Web Public Key Infrastructure (Web PKI), which allows secure, encrypted communication that can be set up by non-specialists. Without encryption, communication between servers and browsers can be read by anyone. When the ecosystem works well, that information is private.

When an end user accesses a website that has an HTTPS URL, they’re interacting with Web PKI. It is a system of everything needed to issue, distribute and verify cryptographic keys and certificates, and tie them to the right domain. At the core of the Web PKI are cryptographic keys that enable cryptographic operations like authentication, authorisation and encryption. A certificate is, essentially, a binding of a cryptographic key (in this case a public key) to a web domain by a Certificate Authority (CA).

Why does CT matter to Web PKI?

CT brings transparency to the SSL/TLS certificate system that supports the web. SSL/TLS protocols underpin HTTPS and Web PKI. A lack of transparency weakens the reliability and effectiveness of encrypted connections, which can compromise critical TLS/SSL mechanisms. As a result, they can enable a wide range of security attacks, such as website spoofing, server impersonation, and man-in-the-middle attacks.

How does Web PKI work?

Web PKI depends on a system of public and private keys. This system is called asymmetric cryptography. Something encrypted with one key of a key pair can only be decrypted with the corresponding key: you can share one of these keys as a public key while keeping the other private. This allows for uses like creating digital signatures and securely exchanging other cryptographic keys. TLS’s use of digital certificates employs both these properties. Digital signatures are used to authenticate a certificate, and the public key in a certificate is used to facilitate negotiating which cryptographic key to use when encrypting a session. Find out more about PKI in this blog post.

How do Certificate Authorities participate in Web PKI?

In Web PKI, Certificate Authorities create digital certificates which map public keys to domains on the internet: the CA is used by User Agents to perform this role. To begin, the website owner generates a new key pair and uses that to generate a Certificate Signing Request (CSR) that is used to prove the website operator controls the private key associated with the public key in the request. Next the website owner proves to the CA that they control their domain, there are a couple of different ways for them to do this. The CA can, for example, ask them to create a DNS record with random value demonstrating they control the domain. Once domain control has been verified, the CA takes the public key from the request and places it, along with the verified domains into a digital certificate that is signed by the CA. It is then returned to the website owner. With the certificate and private key in hand, the domain owner can renew and revoke the certificate.

How do Certificate Authorities work?

Web PKI depends on CAs acting as trustworthy gatekeepers by issuing certificates only to the right parties and by avoiding giving additional permissions accidentally to those parties. An important part of how CAs meet these obligations is to design their systems so they are resilient to failure. That is partly achieved by keeping the most important private keys in vault-like facilities to protect them from physical and logical security threats.

These private keys are associated with what are called "root certificates" which are distributed by user agents as "trust anchors" signaling the holders of the associated private keys are trusted to perform this role. These root certificates and their private keys are used to create intermediate CA certificates (sometimes called missing CAs), each with their own private keys, that are used to issue the web server certificates that make TLS on the web work in real time.

A website then provides its certificate and those of its issuers as a "certificate chain" to the user agent, which in turn uses them to verify that the website certificate is associated with one of these "root certificates". The user agent does this by verifying each certificate signature, ensuring the each certificate in the chain was ultimately issued by a certificate authority that the browser trusts. This process is commonly called certificate chain verification. All of this is described in more detail in RFC 5280.

Certificate Transparency

• How CT works
• Our story

• LogsMonitorsUser agents
• GitHubGoogle Group

Started by engineers at Google, for the internet.