Digital certificates are heavily used in today’s digital world as a means of identity. The information embedded in the certificates lets anyone verify the identity of an entity. In this post, we’ll dig deeper into the format of the most popular type of digital certificates, the X.509 certificates. The X.509 is detailed in RFC 5280 .
Apart from the regular stuff, I would also present some fun facts about the certificates. Lets start by exporting a CA certificate from our chrome trust store.
Goto “Settings->Privacy and Security->More->Manage Certificates”
Once exported, dump the certificate into human readable format using openssl.
openssl x509 -in RootCA.cer -text -noout
Version
X.509 supports three versions 1 to 3.
A version 1 certificate can be marked as version 3, although not a good practice.
The standard doesn’t forbids this.
Serial Number
Unique across certificates generated by the CA.
Helps in identifying the certificates uniquely. Standard doesn’t limit the length or the sign (+/-) of the serial numbers.
Beginning September 30th 2016, the CA Browser forum mandated that CAs shall generate certificate serial numbers greater than zero (0) containing at least 64 bits of output.
Due to a misconfiguration of EJBCA software package, that many browser-trusted authorities use to generate certificates, the certificates generated were having an entropy of 63 bits, instead of the mandated 64 bits. When the issue came to light, it resulted in millions of certificates issued by Apple, GoDaddy & Google being revoked.
Signature Algorithm
The actual name of this field according to RFC 5280 is ‘signature’. It contains the name of the algorithm used by CA to sign the certificates.
Issuer
This identifies the issuer of the certificate. It includes a set of attributes like country(C), organization(O), organizational unit(OU) etc. which together form a distinguished name(DN), that uniquely identifies the issuer.
The roots of X.509 lie in the X.500 project under the ITU-T (the International
Telecommunications Union’s standards body). The X.500 project was an effort to build a global telephone book. This answers the presence of country, locality, state etc. in the DN field.
Validity
This gives the certificate validity period.
Back in initial PKI days, it was normal to encounter certificates with 10 years validity period. Later, due to security concerns, the validity was sheared from 10 years to 5 years, and then to 2 years. Following a failed CA Browser Forum vote on one-year certificates, held in August 2019, Apple went ahead to announce that its devices and Safari browser will only support certificates with a validity of maximum 398 days (~1 year 1 month), after August 31st 2020.
Subject
Uniquely identifies the entity whose public key is embedded in the certificate. Similar to issuer field, it uses distinguished name (DN) for identification.
Subject Public Key Info
Contains the public key for the entity and identifies the algorithm with which the key is used.
Issuer Unique ID & Subject Unique ID
These fields were added in X.509 version 2, to handle the possible reuse of subject and/or issuer name over time. It is strongly recommend that names not be reused, and that certificates should not make use of unique identifiers.
The use of Subject Unique ID and Issuer Unique ID is deprecated by IETF
Extensions
These were added in version 3 of X.509. Following is the list of extensions defined:
The extensions can be largely broken down into 2 categories, constraint extensions and informational extensions.
Constraint extensions limit the way in the key in the certificate or the certificate itself could be used, for e.g. basic constraint, key usage, name constraints etc.
Informational extensions contain additional information which may or may not be useful for users, but does not limit the use of certificate in any way. Common informational extensions include key identifiers and alternative names.
This completes our tour of the X.509 certificates, but X.509 is the not the only format used for digital certificates. SSH and PGP both have their own formats, but X.509 is the most prevalent, the sort of certificates that browsers understand and use for HTTPS.
Further Reading: X.509 certificate formats