JEP draft: Certificate Transparency

OwnerJamil Nimeh
Componentsecurity-libs /
Created2016/12/15 00:01
Updated2020/08/25 00:08


Support Certificate Transparency (CT) in JSSE as specified in RFC 6962 and section of RFC 8446.

Success Metrics

The success metrics for the CT feature are different for the client and server:


Certificate Transparency is a solution to the challenge of detecting misissued certificates. Certificate chains are appended to public logs. These logs may be audited by certificate owners to ensure any subsequent certificates logged within their domains of interest are legitimate. RFC 6962 describes the use of the CT solution for TLS server certificates issued by public CAs.

As of today most browsers have implemented CT support and most TLS libraries have at least client-side support for SCT validation and some have server-side support as well. The validation of SCT data during the TLS handshake is a useful security feature for TLS and JSSE should implement it to achieve parity with these other TLS implementations.


This feature will be provided in the SunJSSE TLS implementation. The tasks for implementing CT support will be different for client-side and server-side roles:


The JSSE client must be able to accept SCTs from all three methods as outlined in the specification. These are:

  1. from a signed certificate timestamp list extension embedded in the X.509 TLS server certificate.
  2. from a signed certificate timestamp list extension in a stapled OCSP response. This method of delivery requires that OCSP stapling is active for the TLS handshake (see JEP 249 for more information on OCSP stapling)
  3. from a TLS extension that is asserted in the ClientHello message and delivered to the client either via the ServerHello (for TLS versions <= TLSv1.2) or in the Certificate message (TLSv1.3).

SCTs may be delivered through more than one source and will be collected before verifying signatures on the timestamps. The criteria for passing the SCT check (e.g. number of required valid/trusted SCTs, etc.) is TBD. If a client does not meet the minimum threshold for a passing SCT check a TLS alert will be issued and the connection closed. We may choose to bypass SCT checks if older TLS certificates before a certain cutoff date are presented by the server. Whether to allow a bypass or not, and the cutoff date for this kind of bypass are both TBD. We may also choose to bypass SCT checking requirements for non-public CAs.

Storage/Loading of trusted logs: Logs are untrusted by default and typically provide RSA or ECC keys used to perform the signatures on SCTs. These keys would need to be known to the client and a mechanism for storage of the keys needs to be determined. This may happen through extensions to the Keystore class, the X509ExtendedTrustManager class, or some other approach. This is currently TBD.

Finally, the client can have the entire feature enabled or disabled via the jdk.tls.client.enableCertTransparency System property. By default this will be true for the client.


JSSE Servers automatically have support for SCT delivery via X.509 certificates, and this method requires no changes to JSSE. Likewise, OCSP stapling support exists on the server and therefore no changes are required for SCT delivery via stapled OCSP responses. We may choose to support the signed_certificate_timestamp TLS extension on the server side. This would require changes to the handshaker code for the consumption of the extension in the ClientHello, and the extension's placement into either the ServerHello message (versions <= TLSv1.2) or the Server Certificate message (TLSv1.3). We will also need to investigate a method for caching SCTs so they can be retrieved efficiently on an as-needed basis. Finally we will have the jdk.tls.server.enableCertTransparency System property, true by default, that can enable or disable support for the TLS extension. Disabling it will not prevent SCT delivery via OCSP stapling or via X.509 certificate presentation to the client.


Extensive testing should be done to ensure the feature works properly. Some of the types of tests to be performed are listed below:



Risks and Assumptions

Certificate Transparency Version 2.0 is a revised and improved CT solution. This is still in draft but is far along in the process. It is assumed that this will not quite reach standardization by the time this JEP is completed. CT v2.0 design and requirements should be considered when designing classes and interfaces for this JEP.

Non Goals

Some items pertaining to Certificate Transparency go beyond the scope of the JSSE client and server and will not be addressed as part of this JEP.