Certificate Transparency

ENTERPRISE EDITION This is an EJBCA Enterprise Edition (EE) feature.

Certificate Transparency (CT) is an experimental Internet security standard and open source framework for monitoring and auditing digital certificates. The standard creates a system of public logs that seek to eventually record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates. This section covers the following:


    EJBCA implements Certificate Transparency (CT) as specified in RFC 6962. The purpose of CT is to create public audit logs of all certificates issued by the public SSL/TLS CAs. The presence of audit records is required for EV certificates in Google Chrome as of 2015 (and other web browsers and non-EV certificates to follow). Note that CT is only relevant for CAs issuing public SSL/TLS certificates, other types of CAs should not use CT. More information can be found on the Certificate Transparency website.

    From a CA's point of view, CT works by publishing certificates from the CA to the log servers and retrieving Signed Certificate Timestamps (SCTs) in response. This is a single operation, so requesting an SCT for a certificate also publishes it. The resulting SCTs can then be sent to end-users in a TLS handshake in different ways: in a certificate extension, in a stapled OCSP response, and/or in a TLS extension. EJBCA supports all of these, including combinations. The following sections describe how to configure EJBCA in one or more of these modes.


    Your EJBCA installation needs the EJBCA Enterprise Edition only ct module. Depending on the CT modes you require, there are some extra preparations.

    CT in Certificates

    No extra preparations are needed. Just configure the logs and enable CT in the certificate profiles as described in the sections Adding CT Logs and Activating CT.

    CT in OCSP Responses

    EJBCA supports CT in OCSP responses, both in live OCSP responders and for pre-production of responses. By default, EJBCA will cache up to approximately 100 000 CT response extensions in memory. Excess cached response extensions that have not been requested for 10 seconds are randomly evicted from the cache. The parameters can be adjusted in the file conf/cesecore.properties.

    To use CT OCSP you must also enable the corresponding extension in the OcspKeyBinding of the OCSP Responder:

    1. Select Admin Web > Internal Key Bindings > OcspKeyBindings and choose the Key Binding to edit.

    2. Under OCSP Extensions, select Certificate Transparency SCT.

    3. Click Add and then Save.


    Proceed with configuring CT logs and certificate profiles according to the sections Adding CT Logs and Activating CT.

    CT in a TLS extension

    In this mode, the certificate holder requests SCTs from the logs and includes them in a TLS extension. The CA is not required to do anything, but it is possible to reduce the time it takes until full (merged) audit log records are available by publishing certificates to the logs as soon as they are issued. For configuration details, see Publishing to logs without using the SCTs .

    Publishing to Logs Without Using the SCTs

    EJBCA can asynchronously publish certificates to one or more CT logs, using a Custom Publisher. This feature is intended to be used mainly when using CT in TLS mode or OCSP mode.

    To enable publishing to logs without using SCTS, do the following:

    1. Go to CA Functions>Publishers and add a new publisher with the following configuration:



      Publisher Type

      Custom Publisher

      Class Path



      Leave blank

      No direct publishing, only use queue


      Keep successfully published items in database


      Use queue for CRLs


      Use queue for certificates


    2. Click Save.

      images/s/en_GB/7202/8bb4a7d7a43e6723fe7875221f32b3124c55e6e1/_/images/icons/emoticons/warning.png Note that the publisher has to be enabled in the certificate profiles before publishing becomes active.

    3. Next, to create a service for the publisher, specify the following under System Functions>Services:




      Publisher Queue Process Worker

      Publishers to check

      The previously created publisher.


      Default is 5 minutes and can be changed to several hours.



    Adding CT Logs

    CT log servers are configured under System Configuration. Note that the CT log servers will not be active until enabled per certificate profile.

    The following parameters have to be configured in a log:



    Log URL

    The log URL, for example https://ct.googleapis.com/testtube/.

    Public Key

    The log's public key, in PEM or DER format. Usually this is an Elliptic Curve key.


    Connection timeout in milliseconds, default 5 seconds. Note that certificate issuance and/or OCSP response generation must wait for the log server to respond, so do not set it too high. Note that zero is not a valid value for the timeout.


    Specify which label to place the log under. See CT Log Labels.

    The log server needs to accept certificates issued by your CAs. For local testing you can install your own instance of the sample log server from the CT open source project, and add your root CA to the list of trusted CAs. For a production system (or testing of one), you must contact the log operator to have your root CA added.

    For redundancy, it is recommended to add more logs to each label than the minimum required. That way certificate issuance will not fail if a single log is down. It is also a good idea to specify a short timeout value and/or enable the ct.fastfail.enabled option in conf/cesecore.properties, so a failing log does not slow down all requests.

    Regarding performance, EJBCA will connect to every log having one of the labels selected in the certificate profile, in the order they have been added and in parallel. It will keep fetching SCTs until Maximum number of SCTs is reached. EJBCA will fail issuance if it is unable to fetch at least the number of SCTs given by the parameter Minimum number of SCTs specified in the certificate profile. If the number of retrieved SCTs exceeds the max value, the log(s) last in order will be excluded.

    To change the order in which the logs are contacted, reorganize the logs on the System Configuration page.

    Expire Time Based CT Logs

    As part of the Google CT policy requirements for April 2018, some logs will only accept certificates expiring within a specific year.

    To configure expire time, click Edit for the log after adding it. When configured, EJBCA will only submit to this log if the certificate expired within the year specified for the log.

    CT Log Labels

    It may be a requirement to publish to certain logs and a certain number of logs before issuing a certificate. For example, Google Chrome requires that all EV certificates issued after 1st of January 2015 must be published to at least one CT log operated by Google, at least one log not operated by Google, and to a certain number of logs in total, where the total amount of logs depends on the lifetime of the certificate. This is achieved by grouping logs using labels in 'System Configuration' page. All logs with the same label forms a log group. EJBCA will fail issuance unless it receives at least one SCT from each log group. Log groups are enabled/disabled by selecting/deselecting labels in the certificate profile.

    The parameters Minimum number of SCTs and Maximum number of SCTs can be configured for each certificate profile, either manually or by certificate validity according to CT policy. An example setup complying to Chrome's CT policy could contain the following:

    • A Google logs label containing a set of logs operated by Google, and a label Unlabeled containing a set of logs not operated by Google.

    • A certificate profile with:

      • The labels Google logs and Unlabeled selected.

      • The parameter Minimum number of SCTs set to By validity to let EJBCA select a minimum dynamically based on Chrome's CT Policy.

      • The parameter Maximum number of SCTs set to By validity to only include the number of SCT's required based on Chrome's CT Policy in the certificate.

    EJBCA Audit Logging

    The submission of pre-certificates is logged to the EJBCA audit log. When a pre-certificate has been submitted to the required number of CT log servers, then a SUCCESS is audit logged. Otherwise a FAILURE is logged. If the generation of the pre-certificate fails, then no CT log submission is performed and nothing is logged.

    Activating CT

    CT logs must be activated in your certificate profiles. For more information, see Certificate Transparency.

    Redacting DNS labels in SubjectAlternativeName

    In the SubjectAlternativeName extension, if part of the DNS should be a secret, that part can be redacted and replaced by the String "(PRIVATE)" in the pre-certificate that will be published to the Certificate Transparency Log. For more information, see Certificate Transparency.

    Using an Outgoing Proxy Server to Send to CT Logs

    For security reasons, a common request is using an outgoing proxy server from the CA to the CT logs. The CT log function uses the Java/JBoss proxy configurations and the proxy properties in JBoss can be configured in one of the following ways:

    • In standalone.sh append to JAVA_OPTS:

    • In standalone.xml append to system-properties:

      <property name="http.proxyHost" value="HostName/IPaddress"/>
      <property name="http.proxyPort" value="PortNumber"/>
      <property name="https.proxyHost" value="HostName/IPaddress"/>
      <property name="https.proxyPort" value="PortNumber"/>

    Ensure to reconfigure the proxy settings if you upgrade/change the JBoss instance.