How do CAs deliver CT log proofs?
As of Jan. 1, 2015, all major Certificate Authorities (CAs) should have Certificate Transparency (CT) logging capabilities for EV SSL Certificates. As of May 1, 2018, all major Certificate Authorities (CAs) should have Certificate Transparency (CT) logging capabilities for DV and OV SSL/TLS certificates.
However, the mechanism used to deliver the proofs may vary from CA to CA. ÃÛÌÒTV currently supports all three methods for delivering SCTs. By default, ÃÛÌÒTV will embed SCTs from the two Google logs and the ÃÛÌÒTV log. Embedding SCTs is the simplest way to provide proofs because it requires no action from server operators. Customers interested in using a TLS extension or OCSP stapling should contact us for more information about changes that might be required on their server.
What are SCT delivery methods?
CAs can log certificates in any trusted log where their root is included. Logs process requests for inclusion and respond with a signed certificate timestamp (SCT). The SCT works like a receipt—showing that the certificate will be added to the log within a certain time period (known as the maximum merge delay or MMD). This ensures the certificate is added to the log within a set time but does not slow down issuance or prevent use of the certificate. The largest MMD permitted is 24 hours, meaning all newly issued and logged certificates will show up in a log within 24 hours after the SCT is generated.
The SCT is included with the certificate throughout its lifetime and is part of a supporting the TLS handshake process. This process evaluates SCTs to ensure each once originated from an approved CT log.
CT supports three methods for delivering an SCT with the certificate
Certificate Embedding
CAs can attach the SCT to a certificate by embedding the SCT proofs directly in the certificate’s extensions. Before issuance, the CA submits a precertificate to the log and the log returns the SCT. The CA includes the returned SCTs in the issued certificate as a certificate extension before it is signed by the appropriate intermediate.
This method does not require any server modification or action on the part of the server operator. However, this method requires the CA to obtain SCTs before issuing the certificate.
TLS Extension
Server operators can deliver SCTs outside of the actual certificate using a special TLS extension. After the CA issues the certificate, the server operator submits the certificate to the log. The log sends the SCT to the server operator and the server uses the TLS extension to deliver the SCT during the handshake.
This method reduces certificate size and does not require any action on the part of the CA.
OCSP Stapling
Server operators can also deliver SCTs using Online Certificate Status Protocol (OCSP) stapling. With OCSP stapling, the CA issues the certificate to both the log server and the server operator. The CA returns the SCT to the server operator as part of the server’s request for the OCSP response. This response, which includes the SCT as an extension, is then provided to clients by the server during the TLS handshake.
This method requires the CA to submit the certificate to the log during issuance but allows the CA to deliver the certificate before receiving the SCT. This method also requires the server operator to enable OCSP stapling on the server.
