As of the release of version 6.0.4, EJBCA Enterprise now supports Certificate Transparency RFC6962.
Note that Certificate Transparency is only relevant for CAs issuing public SSL/TLS certificates; other types of CAs mustn't use CT at this time. More information can be found on the CT website.
The specification of Certificate Transparency is still being discussed, and a follow up to RFC6962 will likely be available in the not so distant future, including (among other things) a way to handle private subdomains.
Google Initiative to Increase https Security
Certificate Transparency (CT) is an initiative by Google to increase security and auditability of the https ecosystem itself. These important aims are accomplished by having CAs (CA services using a software such as EJBCA) issue TLS certificates, which are transparently auditable and exactly reveals which certificates have been issued. The purpose of CT is to create public audit logs of all certificates issued by the public SSL/TLS CAs. For example, this means the owners of a certain web domain can monitor CT Log servers, to see if there are any unknown or suspicious TLS certificates issued for their domain. In addition, the presence of audit records is planned to be required for EV certificates in Google Chrome from February 2015. And perhaps later on for other web browsers and non-EV certificates as well.Note that Certificate Transparency is only relevant for CAs issuing public SSL/TLS certificates; other types of CAs mustn't use CT at this time. More information can be found on the CT website.
The specification of Certificate Transparency is still being discussed, and a follow up to RFC6962 will likely be available in the not so distant future, including (among other things) a way to handle private subdomains.
How EJBCA Enterprise perceives Certificate Transparency
From the CA's angle, CT works by publishing pre-certificates from itself to the log servers; then in immediate response, Signed Certificate Timestamps (SCTs) are retrieved. Certificate and timestamp exchange is done within a single operation, so requesting an SCT for a certificate also publishes it. The resulting SCTs can then be sent to end-users in any of three different ways: 1) in a certificate extension (embedded when issuing the real certificate), 2) in a stapled OCSP response extension, 3) and/or in a TLS extension (yes, EJBCA does support all of those methods, including any combination of the three).
The EJBCA Admin Guide describes how to configure EJBCA Enterprise for one or more of the above methods.
The EJBCA Admin Guide describes how to configure EJBCA Enterprise for one or more of the above methods.
For more information, contact:
Posts
