X.509 Certificate And PKI

Certificates

Certificates are data structures used for identify presentation and verification.

X.509 certificates are crucial for the functioning of TLS and TLS-based protocols such as HTTPS, where certificates are used to prove identitities of websites.

Certificates are also used in secure messaging standards such S/MIME, VPN Solutions such as OpenVPN, software signing and IPsec.

X.509 Certificate

Data structure standard that is used for identity presentation and identity verification.

X.509 ceritificate binds an identity to a public key using a digital signature.

Fields in a typical certificate:

X.509 version: Modern certificates have version 3
Serial number: The unique number of the certificate among certificates signed by the same issuer.
Signature Algorithm: Denotes the Cryptographic Hash Function and digital signature algorithm used to sign the certificate
Issuer: The entity that signed the certificate or the entity that issued the certificate. The issuer is presented in the Distinguished Name (DN) format.
Validity: The two timestamp field Not Before and Not After defining when the certificate is valid.
Subject: The entity that the issuer or the certificate identifies
Certificate’s Public Key: The publick key is very important for the identity verification that the certificate provides. Different key types are supported like RSA, DSA, ECDSA and EdDSA. An X.509 certificate never contains a private key, always a public key
Certificate Signature: Produced by the certificate issuer.

X.509 certificates are encoded using the Abstract Syntax Notation One (ASN.1) into Distinguished Encoding Rules (DERs) or Privacy-Enhanced Mail (PEM) format.

X.509 certifiates’ subject and issuer fields are represented in DN format. A Distinguished Name looks like this: C = US, 0 = Let’s Encrypt, CN = R3.

A DN consists of Key-Value pairs. C → Country, O → Organization, CN → Common Name which means name of the entity identified by the certificate. It can be name of website, person’s name or just a name of the certificate itself.

Every X.509 has a corresponding private key. That private key is not included in the certificate but matches the public key that is included in the certificate. This means that a digital signature produced by that private key can be verified using the public key in the certificate.

The owner of the certificate needs the private key in order to prove that they really own the certificate. Such proof can be established by the owner signing some data with the private key and the verifying party verifying the signature using the public key in the certificate.

X.509 certificate can be freely distributed but the private key should never be. Theft of the private key can lead to identity theft.

Ways to mitigate identity theft are:

Certificate Revocation Lists (CRLs)
Online Certificate Status Protocol (OCSP)

Each X.509 certificate is signed by some certificate. That signing certificate is specified in the Issuer field in the DN format. A certificate can be signed by it’s own private key also. Such a certificte is called a self-signed certificate. They have the same DN in both the subject and the issuer fields. A certificate can be signed by a second certificte and that certificate in-turn can also be signed by another certificate. In this case it’s called a certificate signing chain.

Understanding Certificate Signing Chains

Ordered collection of certificates where each certificate is signed by the certificate preceding it. Except the last certificate, which has to be self-signed.

Verifying identity using a X.509 certificate, we have to verify 2 claims:

Whoever presents the certificate for identification owns the certificate. This claim is proven using the certificate’s private key.

The presented certificate is valid. This is proved using the Certificate Signing Chain.

Most website certificates on the internet are issued by organisations called Certificate Authorities (CAs). A CA is an organisation that issues the certificate and usually charges money. Some CAs like Let’s Encrypt issue certificates for free. CAs present themselves as trusted third parties. The idea is, you trust CAs to issue certificates and consider certificates issued by those CAs valid. You trust that the CAs will check the identities of those who order a certificate from the CA and issue a certificate only to those whose identity match the identity written in the certificate’s Subject field.

Let’s take an example of verifying a website. The first certificate in the chain will be the cert that identifies the website. That certificate did not sign or issue any other certs. Certs that do not sign other certs are called Leaf Certificates.

The website cert will be signed by a second cert, which will not be a self-signed cert. Certs that sign other certs and themselves are not self-signed are called Intermediate CAs Certificates. After multiple Intermedia Certs the last certificate will be self-signed and are called Root CA Certificates.

Intermediate CA Requirement:

If an intermediate CA is compromised it can be revoked without revocation of the Root CA and other Intermediate CAs signed by the root CA. Hence the impact is limited.

Many CAs support automatic issuing of certificates online. This means that the private key of the CA is readily available by the issuing system. Such accessibility is a risk. It is better to put an Intermediate CA at risk, rather than the Root CA. As the root certiicate is rarely used it, the private key can be safely stored offline.

Many intermediate CAs mean that the CRLs are also small and limited and doesn’t need to be very large.

Going back to the previous example, a browser or an HTTPS client is in charge of verifying the entire certificate signing chain. Browser organisations or the OS organisations maintain certificate stores that also include Root CA Stores and decides which CAs are considered trusted.

How are X.509 Certificates Issued

The applicant (future certificate owner) generates the certificate’s private and public keys.

The applicant generates a Certificate Signing Request (CSR). The CSR contains the Subject, Public Key of the future certificate, X.509v3 extensions requested by applicant, CSR Signature. The CSR is signed by the certificate’s private key.

The applicant sends the CSR to a CA for signing.

The CA checks the applicant’s identity.

The CA makes a cert based on info in the CSR. The CA also adds other info to the certificate like, issuer, validity fields, X509v3 extensions. Finally the CA signs the certificate.

The CA sends the cert back to the applicant, who then becomes the cert owner.

The way a CA checks the identity is basically:

Applicant controls the website and the DNS of the website domain

Checks are automated and can be perfomed in the following ways:

Place specific file at specific URL on the website
Add specific DNS record to the website domain
Create email address in the site domain and receive password at that email

That’s why these certs are also somtimes called Domain-Validated (DV) certs.

Websites can perform phishing activities or distribute malwares but can still have a valid cert. All the cert does is to make sure that there is no MITM or DNS Poisoning Attacks.

There are however other types of certs that represents specific organisations and not only specific domain names. Such certs are called Extended Validation (EV) certs and are only given to Organisations and not individuals. When giving EV certs, the CA performs more checks on the CSR:

CSR has come from the organisation that owns the domain

Organisation name in the Subject matches real organisation name

Organisation exists and Govt registered organisation

Organisations phone and address are real

Person requesting cert has the authority to request on behalf of the organisation

X509v3 Extensions

Additional fields that can be added to an X509 certificate. X509v3 extensions can provide contraints or provide additional information on the certificate.

As an example let’s go through X509v3 extensions on the openssl.org website ceritifcate:

Key Usage and Extended Key Usage: Constraint that restrict usage of certificates for only some purpose. It is upto the software that is going to read this extension to abide by the constraint.

CA:FALSE Basic Constraint: Asserts that the cert must not be used to issue other certs

Subject Key Identifier And Authority Key Identifier: Help to look up issuer cert from the issued cert.

These are not mandatory parts of a X509 cert but this makes the usage of a cert more convenient. Also some softwares that verify certs may expect certain v3 extensions and change the verification result based on their presence or absence.

Generating Self-Signed Certificate

First let’s generate a key pair. Let’s use ED448 as the key type.


openssl genpkey -algorithm ED448 -out root_keypair.pem

Let’s inspect the newly created key


openssl pkey -in root_keypair.pem -noout -text

Let’s generate a CSR. To keep things simple we will not add many X509v3 extensions.


openssl req -new -subj "/CN=Root CA" -addext "basicConstraints=critical,CA:TRUE" -key root_keypair.pem -out root_csr.pem

The “CA:TRUE” extension states that we will use it to generate CA certs

Let’s inspect the CSR


openssl req -in root_csr.pem -noout -text

Now let’s generate a self-signed certificate using the CSR and the key pair. The new cert will have a validity period of 3650 days.


openssl x509 -req -in root_csr.pem -copy_extensions copyall -key root_keypair.pem -days 3650 -out root_cert.pem

The -copy_extensions copyall switch is important to copy extensions from the CSR to the produced certs.

Let’s inspect the new self-signed cert


openssl x509 -in root_cert.pem -noout -text

Note that the Issuer and the Subject fields are the same, which is an indication of a self-signed cert.

This cert can now be used as a root CA cert to sign other certs.


~/opensslcodes/certs:openssl genpkey -algorithm ED448 -out root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl pkey -in root_keypair.pem -noout -text
ED448 Private-Key:
priv:
    fe:a8:dd:5b:9f:c9:08:4a:7f:28:03:39:2e:d4:f5:
    5d:02:2a:04:74:a2:d1:16:d4:79:e2:57:1f:24:2f:
    fd:b4:27:9f:c4:0a:71:0e:26:d4:22:d4:a6:c4:0d:
    48:2d:f0:4a:b1:e9:dd:13:50:97:e8:03
pub:
    95:37:52:97:9b:2c:6d:99:f9:f9:48:45:2d:5c:67:
    a0:30:8d:67:af:33:ff:cf:11:07:92:18:07:b1:80:
    4f:81:fa:a7:2c:10:3f:f0:1c:6a:4e:19:43:92:5f:
    50:c3:9d:5a:ca:b1:11:f9:28:29:5b:80
~/opensslcodes/certs:

~/opensslcodes/certs:ls -lh
total 4.0K
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl req -new -subj "/CN=Root CA" -addext "basicConstraints=critical,CA:TRUE" -key root_keypair.pem -out root_csr.pem
~/opensslcodes/certs:
~/opensslcodes/certs:ls -lh
total 8.0K
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:openssl req -in root_csr.pem -noout -text
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: CN = Root CA
        Subject Public Key Info:
            Public Key Algorithm: ED448
                ED448 Public-Key:
                pub:
                    95:37:52:97:9b:2c:6d:99:f9:f9:48:45:2d:5c:67:
                    a0:30:8d:67:af:33:ff:cf:11:07:92:18:07:b1:80:
                    4f:81:fa:a7:2c:10:3f:f0:1c:6a:4e:19:43:92:5f:
                    50:c3:9d:5a:ca:b1:11:f9:28:29:5b:80
        Attributes:
            Requested Extensions:
                X509v3 Basic Constraints: critical
                    CA:TRUE
    Signature Algorithm: ED448
    Signature Value:
        65:22:e6:cd:ba:52:e5:6e:04:6c:32:62:08:25:89:f2:29:33:
        07:57:ad:5d:da:29:4c:18:9c:6b:06:cb:d6:c1:1c:f7:e9:56:
        55:39:14:6d:fe:ce:1d:dc:be:eb:31:f7:fd:6d:25:26:35:e2:
        b7:17:00:71:88:1f:e0:cc:0b:fd:6b:e8:db:04:0e:64:55:ee:
        9a:22:e4:58:e5:0e:35:8b:56:ab:59:50:23:c8:98:b4:19:58:
        d2:99:3f:17:97:57:12:63:73:94:7e:2b:ba:6e:96:b1:a8:62:
        c4:be:3f:74:1a:00
~/opensslcodes/certs:


~/opensslcodes/certs:ls -lh
total 8.0K
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl x509 -req -in root_csr.pem -copy_extensions copyall -key root_keypair.pem -days 3650 -out root_cert.pem
Certificate request self-signature ok
subject=CN = Root CA
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:ls -lh
total 12K
-rw-r--r-- 1 root root 542 Jun  9 11:25 root_cert.pem
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl x509 -in root_cert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            78:e5:73:3e:bc:c8:59:0b:3f:94:e4:f2:a2:68:85:76:ef:6a:6c:97
        Signature Algorithm: ED448
        Issuer: CN = Root CA
        Validity
            Not Before: Jun  9 11:25:37 2024 GMT
            Not After : Jun  7 11:25:37 2034 GMT
        Subject: CN = Root CA
        Subject Public Key Info:
            Public Key Algorithm: ED448
                ED448 Public-Key:
                pub:
                    95:37:52:97:9b:2c:6d:99:f9:f9:48:45:2d:5c:67:
                    a0:30:8d:67:af:33:ff:cf:11:07:92:18:07:b1:80:
                    4f:81:fa:a7:2c:10:3f:f0:1c:6a:4e:19:43:92:5f:
                    50:c3:9d:5a:ca:b1:11:f9:28:29:5b:80
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                8E:D9:94:FF:7F:72:38:33:D5:4F:D4:8F:53:1B:94:66:6E:21:31:57
    Signature Algorithm: ED448
    Signature Value:
        8e:86:de:0c:34:dd:b1:53:c3:f7:d7:b1:d7:76:7c:4b:18:f3:
        e8:96:45:72:5f:b5:7e:d5:9b:61:84:08:2d:75:71:0c:c6:3d:
        32:7d:ca:b1:3c:6f:90:b3:c9:70:7a:5a:2a:b3:a4:e7:f7:88:
        87:ab:00:e9:5f:17:7a:25:0f:c7:3a:f4:e0:0d:bf:b5:37:f5:
        05:02:0d:cc:88:0e:cc:bc:06:df:df:10:61:68:0d:48:af:5d:
        d4:5e:c3:a8:69:0c:6c:f5:3b:bc:a5:64:ef:0a:6a:29:5e:8c:
        15:e9:7e:bc:29:00

Generating Non-Self-Signed Certificate

Let’s generate a couple of non-self-signed certs. One will be used as an intermediate CA cert and the other will be an end-entity leaf cert.

Let’s generate a keypair for the intermediate CA cert


openssl genpkey -algorithm ED448 -out intermediate_keypair.pem

Let’s generate a CSR now


openssl req -new -subj "/CN=Intermediate CA" -addext "basicConstraints=critical,CA:TRUE" -key intermediate_keypair.pem -out intermediate_csr.pem

Now we will issue the intermediate CA cert signing it with the private key of the root cert.


openssl x509 -req -in intermediate_csr.pem -copy_extensions copyall -CA root_cert.pem -CAkey root_keypair.pem -days 3650 -out intermediate_cert.pem

The -CA switch is needed for copying the CA cert’s Subject value into the issued cert’s Issuer field and also for taking other necessary information from the issuinf cert like the Authority Key Identifier

Let’s inspect the issued intermediate CA cert


openssl x509 -in intermediate_cert.pem -noout -text

Let’s now issue a leaf cert and sign it with the private key of the intermediate CA cert.


openssl genpkey -algorithm ED448 -out leaf_keypair.pem

openssl req -new -subj "/CN=leaf" -addext "basicConstraints=critical,CA:FALSE" -key leaf_keypair.pem -out leaf_csr.pem

openssl x509 -req -in leaf_csr.pem -copy_extensions copyall -CA intermediate_cert.pem -CAkey intermediate_keypair.pem -days 3650 -out leaf_cert.pem

Let’s inspect


openssl x509 -in leaf_cert.pem -noout -text


~/opensslcodes/certs:ls -lh
total 12K
-rw-r--r-- 1 root root 542 Jun  9 11:25 root_cert.pem
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl genpkey -algorithm ED448 -out intermediate_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:ls -lh
total 16K
-rw------- 1 root root 156 Jun  9 11:36 intermediate_keypair.pem
-rw-r--r-- 1 root root 542 Jun  9 11:25 root_cert.pem
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl req -new -subj "/CN=Intermediate CA" -addext "basicConstraints=critical,CA:TRUE" -key intermediate_keypair.pem -out intermediate_csr.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:ls -lh
total 20K
-rw-r--r-- 1 root root 432 Jun  9 11:36 intermediate_csr.pem
-rw------- 1 root root 156 Jun  9 11:36 intermediate_keypair.pem
-rw-r--r-- 1 root root 542 Jun  9 11:25 root_cert.pem
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:

~/opensslcodes/certs:openssl x509 -req -in intermediate_csr.pem -copy_extensions copyall -CA root_cert.pem -CAkey root_keypair.pem -days 3650 -out intermediate_cert.pem
Certificate request self-signature ok
subject=CN = Intermediate CA
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:ls -lh
total 24K
-rw-r--r-- 1 root root 599 Jun  9 11:37 intermediate_cert.pem
-rw-r--r-- 1 root root 432 Jun  9 11:36 intermediate_csr.pem
-rw------- 1 root root 156 Jun  9 11:36 intermediate_keypair.pem
-rw-r--r-- 1 root root 542 Jun  9 11:25 root_cert.pem
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem


~/opensslcodes/certs:openssl x509 -in intermediate_cert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1a:5f:f4:a1:a7:14:63:72:03:21:97:7b:e1:8d:a3:d5:71:de:5e:db
        Signature Algorithm: ED448
        Issuer: CN = Root CA
        Validity
            Not Before: Jun  9 11:37:55 2024 GMT
            Not After : Jun  7 11:37:55 2034 GMT
        Subject: CN = Intermediate CA
        Subject Public Key Info:
            Public Key Algorithm: ED448
                ED448 Public-Key:
                pub:
                    60:8c:61:7f:c8:56:6b:67:c9:65:f7:0c:c5:00:e1:
                    b7:bb:1b:15:a0:18:a3:ee:41:75:eb:aa:3d:2f:bd:
                    21:44:9b:8e:be:aa:83:69:9c:66:c3:22:36:e4:c6:
                    aa:bf:3e:b9:d8:b5:72:aa:49:53:c6:00
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                86:F5:1E:76:E4:E8:4B:22:83:0A:81:2F:B3:EA:E1:BD:1A:AC:A5:DD
            X509v3 Authority Key Identifier:
                8E:D9:94:FF:7F:72:38:33:D5:4F:D4:8F:53:1B:94:66:6E:21:31:57
    Signature Algorithm: ED448
    Signature Value:
        a0:c9:10:40:27:1b:52:1c:87:b7:6c:12:8c:c7:c4:ec:14:31:
        ec:52:91:b2:73:2a:b7:f8:a6:43:91:d2:61:bf:bd:e7:4a:31:
        bc:97:f6:d9:49:b0:91:2b:99:94:5f:af:b4:e0:7e:73:89:ff:
        63:52:80:c2:8f:63:c6:b6:76:14:b0:cd:cf:0c:0d:47:ea:73:
        c0:88:d0:ca:5c:2c:f5:33:86:c2:2b:06:7a:80:1a:93:bc:d6:
        92:ca:6c:46:50:62:51:a7:2c:0c:0e:f7:37:18:48:b7:24:d3:
        2e:59:6b:db:16:00
~/opensslcodes/certs:


~/opensslcodes/certs:ls -lh
total 24K
-rw-r--r-- 1 root root 599 Jun  9 11:37 intermediate_cert.pem
-rw-r--r-- 1 root root 432 Jun  9 11:36 intermediate_csr.pem
-rw------- 1 root root 156 Jun  9 11:36 intermediate_keypair.pem
-rw-r--r-- 1 root root 542 Jun  9 11:25 root_cert.pem
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl genpkey -algorithm ED448 -out leaf_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl req -new -subj "/CN=leaf" -addext "basicConstraints=critical,CA:FALSE" -key leaf_keypair.pem -out leaf_csr.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl x509 -req -in leaf_csr.pem -copy_extensions copyall -CA intermediate_cert.pem -CAkey intermediate_keypair.pem -days 3650 -out leaf_cert.pem
Certificate request self-signature ok
subject=CN = leaf
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:ls -lh
total 36K
-rw-r--r-- 1 root root 599 Jun  9 11:37 intermediate_cert.pem
-rw-r--r-- 1 root root 432 Jun  9 11:36 intermediate_csr.pem
-rw------- 1 root root 156 Jun  9 11:36 intermediate_keypair.pem
-rw-r--r-- 1 root root 591 Jun  9 11:55 leaf_cert.pem
-rw-r--r-- 1 root root 412 Jun  9 11:55 leaf_csr.pem
-rw------- 1 root root 156 Jun  9 11:55 leaf_keypair.pem
-rw-r--r-- 1 root root 542 Jun  9 11:25 root_cert.pem
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl x509 -in leaf_cert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            30:ea:cd:4b:b3:cf:36:37:45:8c:cd:dd:4a:30:5c:27:ef:c9:92:86
        Signature Algorithm: ED448
        Issuer: CN = Intermediate CA
        Validity
            Not Before: Jun  9 11:55:40 2024 GMT
            Not After : Jun  7 11:55:40 2034 GMT
        Subject: CN = leaf
        Subject Public Key Info:
            Public Key Algorithm: ED448
                ED448 Public-Key:
                pub:
                    ce:65:3d:73:2f:8a:cb:db:31:08:97:82:36:06:b2:
                    cd:5d:1b:5b:0a:c4:f6:62:06:e4:a4:36:47:02:de:
                    b7:f1:d6:ef:a0:02:6f:46:c7:d4:9d:51:f4:20:b9:
                    6f:95:90:d2:b5:60:52:eb:a5:a1:e5:00
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                43:F1:F2:08:3A:39:22:91:8D:33:1A:1B:16:DA:2D:CA:D6:EC:F1:F3
            X509v3 Authority Key Identifier:
                86:F5:1E:76:E4:E8:4B:22:83:0A:81:2F:B3:EA:E1:BD:1A:AC:A5:DD
    Signature Algorithm: ED448
    Signature Value:
        64:10:35:a7:99:39:e0:41:c1:a0:f6:f9:f7:8d:1e:72:07:f6:
        52:44:78:f7:21:46:98:03:67:0f:e3:72:7b:45:02:5d:92:d7:
        04:15:bb:9c:ec:7a:b2:6f:e5:81:fc:56:19:31:62:d3:f5:f9:
        2d:8f:00:64:74:c0:12:62:0d:58:2a:9b:49:d6:d8:f9:c2:dd:
        cd:8e:c2:24:b8:4f:5c:21:73:ad:cb:63:ef:ef:4c:8a:20:fe:
        7b:4a:1c:33:3c:b9:ca:75:8e:b6:7f:76:39:dd:34:60:33:16:
        94:94:dd:84:0f:00
~/opensslcodes/certs:

Verifying Certificate

Let’s verify the leaf cert. We will consider our root CA cert a trusted cert, our intermediate CA certs will be considered untrusted, but it will help us to build the cert signing chain.


openssl verify -verbose -show_chain -trusted root_cert.pem -untrusted intermediate_cert.pem leaf_cert.pem

The -trusted switch is used to specify a file containing one or more trusted certs and the -untrsuted for the untrusted certs. In order to verify a cert, openssl verify has to build a cert signing chain from the cert being verified up to a trusted cert. Both the switches can be used multiple times.


~/opensslcodes/certs:ls -lh
total 36K
-rw-r--r-- 1 root root 599 Jun  9 11:37 intermediate_cert.pem
-rw-r--r-- 1 root root 432 Jun  9 11:36 intermediate_csr.pem
-rw------- 1 root root 156 Jun  9 11:36 intermediate_keypair.pem
-rw-r--r-- 1 root root 591 Jun  9 11:55 leaf_cert.pem
-rw-r--r-- 1 root root 412 Jun  9 11:55 leaf_csr.pem
-rw------- 1 root root 156 Jun  9 11:55 leaf_keypair.pem
-rw-r--r-- 1 root root 542 Jun  9 11:25 root_cert.pem
-rw-r--r-- 1 root root 420 Jun  9 11:18 root_csr.pem
-rw------- 1 root root 156 Jun  9 11:09 root_keypair.pem
~/opensslcodes/certs:
~/opensslcodes/certs:
~/opensslcodes/certs:openssl verify -verbose -show_chain -trusted root_cert.pem -untrusted intermediate_cert.pem leaf_cert.pem
leaf_cert.pem: OK
Chain:
depth=0: CN = leaf (untrusted)
depth=1: CN = Intermediate CA (untrusted)
depth=2: CN = Root CA
~/opensslcodes/certs: