Certificate Transparency aims at increasing safety with TLS certificates. Most importantly CT was put in the place to defend mis-issuance.
Certificate Transparency aims to remedy these certificate-based threats by making the issuance and existence of SSL certificates open to scrutiny by domain owners, CA, and domain users. Specifically, Certificate Transparency has three main goals:
Certificate Logs
Certificate logs are simple network services that maintain cryptographically assured, publicly auditable, append-only records of certificates. Anyone can submit certificates to a log, although certificate authorities will likely be the foremost submitters.
Likewise, anyone can query a log for a cryptographic proof, which can be used to verify that the log is behaving properly or verify that a particular certificate has been logged.
The number of log servers doesn’t have to be large (say, much less than a thousand worldwide), and each could be operated independently by a CA, an ISP, or any other interested party.
Monitors
Monitors are publicly run servers that periodically contact all of the log servers and watch for suspicious certificates.
For example, monitors can tell if an illegitimate or unauthorized certificate has been issued for a domain, and they can watch for certificates that have unusual certificate extensions or strange permissions, such as certificates that have CA capabilities.
A monitor acts much the same way as a credit-reporting alert, which tells you whenever someone applies for a loan or credit card in your name. Some monitors will be run by companies and organizations, such as Google, or a bank, or a government.
Others will be run as subscription services that domain owners and certificate authorities can buy into. Tech-savvy individuals can run their own monitors.
Auditors
Auditors are lightweight software components that typically perform two functions. First, they can verify that logs are behaving correctly and are cryptographically consistent.
How Certificate Transparency works?
Components of Certificate Transparency
- Certificate Authorities CA (Comodo, DigiCert, Verisign, Thawte)
- Log Servers that act as public repositories for the certificate records.
- The browsers of any client accepting certificates (they act as auditors)
- Publicly run servers that monitor newly added certificate logs to check for mis-issuances
The following occurs when a CA logs a certificate:
- The CA creates what is called a “pre-certificate,” which contains the SSL Certificate’s information. The CA then sends this pre-certificate to its trusted Log server.
- The Log server then accepts this information and returns a “signed certificate timestamp” or SCT. The SCT essentially promises to log the certificate within a certain period of time. This time frame is known as the Maximum Merge Delay or MMD—it may never exceed 24 hours.
- The SCT is then accepted by the CA and added to the body of the SSL Certificate (or sometimes presented by other means). The SCT’s presence is, itself, a signal that the certificate has been published in a CT log.
There are three ways for an SCT to be delivered with the SSL Certificate:
- X509v3 Extension
- TLS Extension
- OCSP Stapling
Advantages of Certificate Transparency
- Early detection of misissued certificates, malicious certificates, and rogue CAs.
- Faster mitigation after suspect certificates or CAs is detected.
- Better oversight of the entire TLS/SSL system.
