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.
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
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.
A 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.
Anyone 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).
Logs maintain a record of certificates. They use a special cryptographic mechanism, a Merkle tree, to allow public audits. Logs are:
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.
Each 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.
The 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.)
Monitors 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.
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).
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.
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.
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.
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.