PKIX — Public Key Infrastructure Using X.509 Certificates

9 min readJan 3, 2019

This is an installment to the series of stories describing PKI.

So, till now, what we know? There has to be a certificate authority, whom our browser(or us) needs to trust, and whenever we connect to a website over HTTPS, we receive a certificate, which, our browser validates against something or some information about the certificate authority. Let us briefly discuss what actually the browser validates and how.

Digital Signatures

A digital signature is a cryptographic primitive that ascertains non-repudiation. In other words, anyone can validate the source of some information as well as the authenticity. Digital signatures are based on Public Key Cryptography, where, there is a public-private key pair. There is a signer, who uses her private key to sign some information, thus generating a signature, essentially an octet sequence of a fixed length. Under the hood, it just boils down to computing the hash of the information to be signed and encrypting the hash with the private key. The signature thus generated is decryptable by the public key.

So, for verification, anyone who has access to the data, the signature and the public key corresponding to the private key can validate the source. That is, one can compute the hash of the info, and then decipher the signature to get the hash from the signature using the public key, and then match it with the hash one computed. If they match, it is guaranteed, that the owner of the public key has signed the information. There are a few common known algorithms available in the public domain such as sha2WithRSA — (hash the info with SHA2 and encrypt using RSA), sha1WithRSA and so on..

The X.509 Certificate

Now, as in the previous installment we discussed what a certificate does, it basically binds the credentials to an entity. Now you would ask what credentials, basically the public key. So, a certificate binds a public key to its owner. And how does it do that? The answer is, it contains a signature by a trusted certificate authority. The signature is computed on the information present in the certificate signing request with some additional information. Which is, a public key, the DN(Distinguished Name — refer X.500 directory services rfc) of the entity owning the public key and a few other details like address fields, and majorly the IssuerDN. Once the certificate authority computes the signature, it produces a digital certificate primarily containing the public key, the distinguished name of the owner, the issuer’s distinguished name, the validity, the signature, signature algorithm. The information is encoded in ASN.1 format.

So, if you know the public key of the Issuer and you have the certificate, you can easily validate the signature and ascertain that the information in the certificate is authentic, i.e. the public key present in the certificate, indeed belongs to the owner claiming to own it. Once you have validated the public key, you can go ahead and encrypt your data and send it to the recipient(often a server) which/who has the private key to decrypt the information you sent. Though in the ideal world, there is much more to secure communication with a server over https than this. But, I guess you get the basic mechanics.

The Trust Chain

One point to note is, often the CA that signs a CSR is an intermediate one. That is, there is a root CA whose private key is used to sign the certificate of an intermediate CA. Once the signing is done, the private key of the root CA is kept in a very secure location. The public key of the root CA is distributed in the form a self signed certificate, i.e. the root CA signs its own certificate before it is distributed. All the certificates after that are signed using the intermediate CA, also called subordinate CA.

To ensure trust, one has to validate the certificate chain. That is, once a certificate is received, intermediate CA’s public key is used to validate the signature. Once that is done, intermediate CA’s signature is validated with the root CA’s public key that was distributed earlier and is present with everyone(often stored in our browser’s trust store). Thus the root CA certificate, since it acts as the root of the trust chain, is called the trust anchor.

Fields In An X.509 Certificate

Since the X.509 certificate is basically a data structure that binds the credential with the identity with the help of a signature and a trusted certificate authority. It contains some fields, let’s discuss the major ones:

Issuer: It is the distinguished name of the entity that issued the certificate, or in other words, computed the signature present in the certificate.

Subject: The distinguished name of the entity to which the credential belongs(usually the public key).

Signature Algorithm: It is the algorithm that was used to compute the digital signature.

Version: The version of the certificate. The older versions were not flexible but v3 supports extensions.

Common X.509v3 Extensions

There are a few extension fields that help in the formation of the certification chain, that we referred to in the first installment.

Authority Key Identifier(AKI): It is basically a SHA1 hash of the issuer’s public key and is used to identify a specific public key if there are multiple.

Subject Key Identifier(SKI): It is the SHA1 hash of the public key held by the subject.

Subject Alternative Names: This is optional and represents any other names to which the certificate might be bound to, and is generally used with websites(i.e. with certificates issued to be used with websites containing the domain name).

Relation Between SKI and AKI

Now, how do these fields related among the certificates forming a trust chain? It is quite simple, AKI simply is a hash of the parent’s public key, and, the SKI is the hash of the subject’s public key. So, we can easily derive a relation, the AKI of a child certificate will be equal to the SKI of the parent certificate. The only exception to this rule is, the root CA certificate, which has an AKI equal to its own SKI, and indeed, the root CA is a self signed certificate, so the issuer has issued the certificate to itself.

The AKI is also used to identify the issuer’s certificate, when there are many valid certificates belonging to the Issuer’s DN.

CRL (Certificate Revocation Lists)

Not too often, but there may arise a need to revoke the validity of certificate before it actually expires. For reasons, such as a key compromise or compromise of the whole CA(of which many instances have occurred) or even unspecified(ya, that is also a supported revocation reason that can be specified.

If you open up a PEM encoded CRL, it kinda looks similar to a similarly encoded X.509 certificate or a Certificate Signing Request or any PEM encoded file. It just starts with

The Beginning Of A PEM Encoded CRL File.

The complete stuff may look something like the following:

Underneath all this, its the same old ASN1 encoded binary data representing something.

Well, what is that something?

A signed list of revoked certificates issued by the CA. Yes, it can be verified using the public key obtained from the certificate of the issuer represented by the Subject DN of the the CRL. So, Let’s inspect the fields of a CRL file using our favorite, the OPENSSL command line tool.

As you might have already guessed, the US treasury doesn’t like giving the real reasons behind all those revocations. But you can observe a revocation entry comprises of a the certificate serial number, a revocation date and the reason behind the revocation. And finally there is the signature algorithm and the signature itself. And not oddly enough, yes,

We can verify the signature.

The only trouble being,

And the number of revoked certificates in the CRL?

Imagine the browser downloading that 5.1 MB CRL file from a URL to check if the certificate presented by the server is present among the 142600 certificates revoked by the CA after identifying the CA and validating the signature of the CRL.

A certificate may contain a CRL Distribution Point extension containing the exact URL from where to get the CRL from.

Obviously this is not scalable for CAs which might have thousands and even millions of revoked certificates.

A scalable alternative was thus necessary, and thus it became the mother of OCSP i.e. Online Certificate Status Protocol.

OCSP (Online Certificate Status Protocol)

As the name suggests, it is online. There is a server that is running somewhere capable of giving the current status of a certificate. And how would you come to know where is the OCSP responder server for a specific certificate? You might have already guessed. An X.509 extension!

For example let us take the Google’s public certificate.

A hell big of a certificate. Well, besides containing the 256 bit Elliptic Curve Public Key(more to come on that later), it contains a lot of SANs or Subject Alternate Names and that is where the majority of the bulk, in this certificate, comes from.

Anyways, if you inspect this certificate using openssl x509 utility like I did:

openssl x509 -in google-cert.pem -text

You will see an X.509 extension:

The Authority Information Access Extension

And there you go, you have the OCSP responder for this certificate, and well, the CA Issuers field points to something. Though not a convention, but google seems to be following one here, the OCSP responder endpoint is gts1c3 having the same name as the file that is hosted at http://pki.goog/repo/certs/gtsr1.der

So, I went ahead and downloaded the gtsr1.der file from that pki.goog url and tried cat’ing it, and it was some binary junk. And since the extension was der, suspecting it to be a DER encoded file, I happily ran:

openssl x509 -in gts1c3.der -inform DER -text

And voila! It indeed was the issuer certificate containing the public key that could be used to verify the OCSP responder’s response.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            02:03:bc:53:59:6b:34:c7:18:f5:01:50:66
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Aug 13 00:00:42 2020 GMT
            Not After : Sep 30 00:00:42 2027 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:f5:88:df:e7:62:8c:1e:37:f8:37:42:90:7f:6c:
                    87:d0:fb:65:82:25:fd:e8:cb:6b:a4:ff:6d:e9:5a:
                    23:e2:99:f6:1c:e9:92:03:99:13:7c:09:0a:8a:fa:
                    42:d6:5e:56:24:aa:7a:33:84:1f:d1:e9:69:bb:b9:
                    74:ec:57:4c:66:68:93:77:37:55:53:fe:39:10:4d:
                    b7:34:bb:5f:25:77:37:3b:17:94:ea:3c:e5:9d:d5:
                    bc:c3:b4:43:eb:2e:a7:47:ef:b0:44:11:63:d8:b4:
                    41:85:dd:41:30:48:93:1b:bf:b7:f6:e0:45:02:21:
                    e0:96:42:17:cf:d9:2b:65:56:34:07:26:04:0d:a8:
                    fd:7d:ca:2e:ef:ea:48:7c:37:4d:3f:00:9f:83:df:
                    ef:75:84:2e:79:57:5c:fc:57:6e:1a:96:ff:fc:8c:
                    9a:a6:99:be:25:d9:7f:96:2c:06:f7:11:2a:02:80:
                    80:eb:63:18:3c:50:49:87:e5:8a:ca:5f:19:2b:59:
                    96:81:00:a0:fb:51:db:ca:77:0b:0b:c9:96:4f:ef:
                    70:49:c7:5c:6d:20:fd:99:b4:b4:e2:ca:2e:77:fd:
                    2d:dc:0b:b6:6b:13:0c:8c:19:2b:17:96:98:b9:f0:
                    8b:f6:a0:27:bb:b6:e3:8d:51:8f:bd:ae:c7:9b:b1:
                    89:9d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier: 
                8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27
            X509v3 Authority Key Identifier: 
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
            Authority Information Access: 
                OCSP - URI:http://ocsp.pki.goog/gtsr1
                CA Issuers - URI:http://pki.goog/repo/certs/gtsr1.der
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://crl.pki.goog/gtsr1/gtsr1.crl
            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.11129.2.5.3
                  CPS: https://pki.goog/repository/
                Policy: 2.23.140.1.2.1
                Policy: 2.23.140.1.2.2

So, the next step was to hit the OCSP responder and verify the respone against the certificate in file “gts1c3.der”. For this also openssl comes with the ocsp tool, and by invoking the following command, I was able to not only retrieve the OCSP response, the tool also validated the signature of the response as well.

openssl ocsp -issuer gts1c3.der -cert google-cert.pem -text -url http://ocsp.pki.goog/gts1c3

And, the response was good:

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: C72E798ADDFF6134B3BAED4742B8BBC6C0240763
          Issuer Key Hash: 8A747FAF85CDEE95CD3D9CD0E24614F371351D27
          Serial Number: AC6909BD223B505B0A58D0F808992180
    Request Extensions:
        OCSP Nonce: 
            041040330F1127136CEC205EDE075EBE7018
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 8A747FAF85CDEE95CD3D9CD0E24614F371351D27
    Produced At: Aug 16 14:09:56 2022 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: C72E798ADDFF6134B3BAED4742B8BBC6C0240763
      Issuer Key Hash: 8A747FAF85CDEE95CD3D9CD0E24614F371351D27
      Serial Number: AC6909BD223B505B0A58D0F808992180
    Cert Status: good
    This Update: Aug 16 14:09:54 2022 GMT
    Next Update: Aug 23 13:09:53 2022 GMT<Omitting Signature Info>Response verify OK
google-cert.pem: good
 This Update: Aug 16 14:09:54 2022 GMT
 Next Update: Aug 23 13:09:53 2022 GMT

Adios!