Certificate Transparency – Transparency in the Certificate Jungle

Certificate Transparency (short CT) is a system for checking and monitoring digital certificates. It was developed by Google employees Ben Laurie and Adam Langley and proposed as an IETF standard. Google itself is strongly driving the project forward: from October 2017, the Google browser Chrome will classify certificates that are not registered in the CT log as untrustworthy. This forces certificate authorities to participate in Certificate Transparency. Certificate Transparency does not prevent improperly issued certificates, but it will lead to a faster discovery of such certificates by achieving the following goals:

• For a certificate authority, it should be virtually impossible to issue a certificate for a domain without this process being noticed by the domain owner.
• Domain owners and certificate authorities should be able to check whether certificates were issued erroneously or maliciously.
• Users should be protected as much as possible from erroneously or maliciously issued certificates.

Logs, Monitors, and Auditors

Certificate Transparency adds three new components to the existing certificate system: logs, monitors, and auditors. Previously, if a domain owner needed a new certificate, they requested it from their certificate authority, which could issue the certificate after a check. With Certificate Transparency, further steps are added, which are highlighted in blue-italic below and shown in an overview in Figure 1 :

1. The domain owner of example.com acquires a new certificate from their certificate authority.
2. The certificate authority checks the authenticity of the domain owner, i.e., whether they are authorized to request the certificate.
3. The certificate authority generates a pre-certificate.
4. The certificate authority sends the pre-certificate to a CT log, which responds with a signed certificate timestamp (SCT in English).
5. The certificate authority hands over the certificate with the SCT to the domain owner, who then configures their systems.
6. When establishing a connection to example.com, the browser validates the certificate and the signature of the SCT.
7. If the certificate and SCT are in order, an encrypted connection is established with the server and communication takes place over it.

Note: This sequence and Figure 1 describe the issuance of certificates with SCT as an x.509 extension. Other possibilities are described in the Logs section.

Logs

The central element of Certificate Transparency is the logs. New certificates are appended to these in a steadily growing hash tree. The hash tree (English: Merkle Tree) also protects against subsequent manipulation of the log, which can be checked by anyone for erroneously or maliciously issued certificates.
When a certificate is sent to a log, it responds with a SCT, which is equivalent to a promise to enter the certificate into the log by a certain time. During the subsequent connection establishment between client and server, the SCT is also checked. It can be communicated to the client via three ways:

1. as an x.509 parameter of the certificate: the certificate authority adds the SCT just before the signing process. The website operator does not have to make any changes to their configuration.
2. as a TLS parameter during the connection establishment: the website operator must configure the connection establishment so that the SCT is communicated to the client. The certificate authority, on the other hand, does not have to make any changes when issuing certificates.
3. via OCSP stapling: in addition to information on the revocation of certificates, SCTs can also be transmitted. Here too, the website operator must make changes and implement OCSP handling.

Which of these three possibilities will eventually prevail is still unclear. There are good reasons for the 1st way to transmit the SCT as an x.509 extension. This means website operators do not have to make any changes. In return, certificate authorities must rework their issuance process. They must send pre-certificates to logs and wait for the SCT response. That this synchronous process occasionally leads to delays is to be expected: Figure 2 shows the number of Let's Encrypt certificates issued per day. On peak days, more than 1.3 million certificates for Let's Encrypt alone must be entered in logs (the RFC standard recommends entering a certificate in several logs), which requires extensive resources for fast response times.

Monitors

In addition to logs, monitors exist, which watch for suspicious activities in logs. Monitors can be operated, for example, by large internet service providers (Facebook, etc.) or certificate authorities (COMODO and others). But basically, anyone is free to operate their own monitoring service or use the service of a third party. Sslmate offers such a service free of charge for up to five domains.

Since all issued certificates must in the future be reported to logs, "secret" domains and subdomains will also become publicly known, even if the operator would like to keep them secret.

Auditors

Auditors check whether logs are consistent with each other. Furthermore, they are intended to ensure that all certificates have been added to at least one log. Finally, through Log Proofs, it is audited whether a log was manipulated, for example by subsequently adding, editing, or deleting certificate information.

Browsers will in the future contain a software component that acts as an auditor: if encrypted connections are to be established, these modules check the SCT and query logs for the certificate. Likewise, an auditor can be an independent service or a secondary function of a monitor.

Certificate Transparency: A Step in the Right Direction

Certificate Transparency will not prevent certificates from being issued erroneously or maliciously in the future. However, it is possible through CT to notice such a violation quickly and take countermeasures. One countermeasure, usually the revocation of certificates, is a further complex field of themes that has so far been insufficiently solved. Nevertheless, Certificate Transparency is a step in the right direction that gives service providers more control over their domain.