Understanding the Precertificate Format and its Functionality in Certificate Transparency.
Precertificates are a special type of SSL certificate that are used as part of Certificate Transparency (CT). Precertificates are distinguished from a regular SSL certificate in that they are not intended to be (nor can be) used to authenticate a server or form an authenticated connection (such as an HTTPS connection).
Their only purpose is to allow proof that a certificate has been logged to be directly embedded in a certificate (how that works is covered in the following sections).
The name is quite literal; a precertificate comes before a certificate. Precertificates are rarely exposed to end users and you may have received a certificate for which a precertificate exists and never know it.
Precertificates are defined in the Certificate Transparency RFC. This post will explain in plain language what precertificates are, how they are used, and the technical mechanism that makes them work.
Why are Precertificates used?
Precertificates exist to allow certificate transparency data to be embedded directly into a final certificate.
Precertificates are one of a few ways to include proof of submission to a certificate transparency log (the SCT) with a certificate. The advantage of precertificates it that is allows CT data to be embedded in the SSL certificate itself instead of provided as a separate piece of data (other methods require that the SCT is sent as a separate file during the handshake, similar to OCSP Stapling).
The CT log needs to be able to produce a valid signature (SCT) for that certificate’s data. But the CA also needs that SCT from the log before it can create the final certificate. It’s sort of a catch-22. Precertificates solve this problem and allow the log to produce the correct signature without actually having the final certificate.
Here is an overview of the scenario where a precertificate would be used:
- A Certificate Authority (CA) is going to sign and issue a certificate to a client. They need to make it compliant with browsers’ CT policies, so they need to submit the certificate to a CT Log.
- The CA has a few choices for how to deliver proof that a certificate has been logged. If they want to embed that proof directly in the certificate, they will need to use a precertificate.
- Before the CA signs the final certificate, they first create a precertificate, which contains the same data but is formatted a specific way so that it is not treated as a valid SSL certificate.
- The CA submits the precertificate to a CT log and receives an SCT (Signed Certificate Timestamp). This is a file signed by the log which can be used to cryptographically prove to clients that the certificate was logged.
- Now that the CA has the SCT it can put it into the final certificate and include it as part of the signed data. The CA issues the final certificate with the SCT embedded into it.
- The end-user can now deploy their certificate and have proof of their CT compliance contained within their certificate. This is the optimal way to include an SCT.
If you search certificate transparency logs you may come across precertificates but not the associated (valid) certificate. This is because the CA is not required to submit the subsequent certificate to the log. Even though precertificates are not treated as valid by clients, a precertificate is still held to the same issuance standards. The CT RFC states that “misissuance of the Precertificate is considered equal to misissuance of the final certificate.”
How Precertificates Work
A precertificate is distinguished from a regular certificate by a field of data known as an extension in the X.509 v3 format. Extensions give flexibility to the X.509 format and allow the adoption of new features without having requiring a new version of the format. SSL certificates use extensions for a number of features.
Precertificates contain a “poison extension,” which was specifically created for this purpose. It is named this because it is an extension marked as critical (meaning that if it can’t be correctly parsed the certificate is to be treated as invalid) and was designed to not be supported by client software.
This means that when a client (such as a web browser or your operating system) encounter a precertificate they will process the unknown extension, and see that it is critical. The precertificate will then be deemed invalid because there is a critical extension that it dosen’t understand (Hypothetically, if the client did know what the poison extension was it would also mark the certificate as invalid).
Thus the presence of this extension “poisons” the precertificate because it will always be understood to be invalid.
The presence of this “poison extension” is the only difference between a regular certificate and a precertificate (this is true for version 1 of the CT standard. We talk about how this will change in version 2 below).
The poison extension is indicated with a unique OID: 126.96.36.199.4.1.11188.8.131.52. OIDs, or Object Identifiers, are standardized strings that are assigned to certain purposes and used to provide computer-parsable formatting. For example, you can look up that OID number and see that it has been assigned the following purpose: “Certificate Transparency precertificate poison extension.” Other OIDs, like 184.108.40.206.220.127.116.11.1, are used in SSL certificates to indicate the OCSP URL for that certificate.
Let’s take a look at a precertificate to see this in action.
If you download and open a precertificate in Windows it will look very similar to a regular SSL certificate. However, on the General pane of Windows’ Certificate Viewer you will notice it reads “A certificate contains an unknown extension that is marked ‘critical.’” In Details you will see the poison extension listed near the bottom (look for the OID).
Because this extension is present, Windows treats the precertificate as invalid. This prevents it from being used in situations where an SSL certificate would be used – such as in an HTTPS connection. On macOS, the certificate viewer will say “This certificate cannot be used (unrecognized critical extension).”
In version 2.0 of the Certificate Transparency protocol (still under development, RFC6962) the format of precertificates will change from X.509 to CMS (Cryptographic Message Syntax). This will mean that the technical format and encoding of precertificates will drastically change and will no longer be the same format as regular SSL certificates.
This means that the poison extension will no longer be needed when CT 2.0 is deployed because there will be no need to differentiate a precertificate from a valid X.509 SSL certificate.