All major Certificate Authorities (CAs) should have Certificate Transparency (CT) logging capabilities for EV SSL Certificates by January 1, 2015. However, the mechanism used to deliver proofs may vary by CA. Some CAs may offer logging for non-EV certificates, but this is dependent on the CA.

DigiCert supports CT for all of our SSL Certificates. If you would like to enable CT for an existing or new certificate simply contact our support team.

DigiCert currently supports all three methods for delivering SCTs. By default, DigiCert will embed SCTs from the two Google logs and the DigiCert log. Embedding SCTs is the simplest way to provide them initially because it requires no action from server operators. Customers interested in using a TLS extension or OCSP stapling should contact DigiCert for more information about what changes might be required on their server.

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. However, current software does not support this extension, meaning support for the TLS extension must be manually configured by the server operator.

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.