How does certificate transparency work?
Certificate Transparency (CT) works within the existing Certificate Authority (CA) infrastructure as a way to provide post-issuance validation of an entity’s authorization for the issuance of SSL Certificates.
The certificate issuance process is shown below with new steps introduced by CT highlighted in blue.
- Server operator purchases certificate from CA
- CA validates server operator
- CA creates a precertificate
- CA logs the precertificate with the log server, which returns a signed certificate timestamp (SCT)
- CA issues SSL Certificate
- SSL Certificate may include signed certificate timestamp (SCT)
- Browser validates SSL Certificate during the TLS handshake
- Browser validates the SCT provided during the TLS handshake, either through OCSP stapling, through a TLS extension, or from information embedded in the certificate
- Browser makes connection with the server
- SSL Certificate encrypts all data as it is passed from the browser to the server
There are three possible ways to deliver the SCT during the TLS handshake, as explained here. A diagram of this process for one of the SCT delivery methods is included below.
Certificate transparency components
The CT system has four components: CA, certificate log, certificate monitor, and certificate auditor. Below is a diagram with a likely configuration of these components. Each of these components is explained in more detail below.
Certificate authority
CT works within the existing publicly-trusted CA system. With CT, CAs can include evidence of certificate issuance in a public log and browsers can check for these SCTs during the handshake. Logging certificates is evidence of the CA’s proper operation and gives insight on CA operations.
Certificate log
Ideally, certificate logs will maintain a record of all SSL Certificates issued; although the initial rollout is limited to EV certificates. Multiple independent logs are required for several reasons: 1) Multiple logs allow for a backup in the case of a log failure, 2) Independent logs mean that if one log or log operator is compromised, certificates can still be validated; 3) Independent logs mean a single government action cannot remove evidence of issuance from all logs; and 4) Multiple independent logs mean a CA and log operator can’t collude to obfuscate an embarrassing misissuance.
All logs are:
- Append only - Certificates can only be added to a log; they can’t be deleted, modified, or retroactively inserted.
- Cryptographically assured - Logs use a cryptographic mechanism called a Merkle Tree Hash to prevent tampering.
- Publicly auditable - Anyone can query a log and look for misissued or rogue certificates. All certificate logs must publicly advertise their URLs and public key.
Certificate monitor
A certificate monitor is anyone who watches the certificate logs for suspicious activity, like large brand owners or CAs.
Monitors can fetch information from the logs by using an HTTP GET command. Each customer may act as their own log monitoring service or may delegate this to another party. DigiCert plans to provide log monitoring services for its customers.
Certificate auditor
Certificate auditors check the logs to verify that the log is consistent with other logs, that new entries have been added, and that the log has not been corrupted by someone retroactively inserting, deleting, or modifying a certificate.
Auditing will likely be an automated process that is built into browsers. However, auditors could be a standalone service or could be a secondary function of a monitor.
