CompileNix's Blog - The SSL Certificate Chain Creation, Verification, and Trust

Start Page | RSS Feed | Find Stuff

Technical side of things

What is a SSL Certifcate / Keypair?

A SSL keypair is a combination of a private key and a public key used for secure communication. The private key is kept secret by the owner and the public key is shared with others. A certificate is a digital document that contains information about the owner of a public key, including the domain name, public key, and signature of the issuer. The certificate is used to secure communication between a client and a server by establishing trust in the identity of the certificate owner.

In short, a certificate is a digital identity card that is verified by a trusted third party and used to secure communication. This verification process involves creating an SSL certificate chain, which consists of the following components:

  1. Create Root CA Certificate
  2. Create Intermediate CA Certificate
  3. Create Leaf Certificate

We will explain each of these components in detail, along with the process of revoking a leaf certificate and a brief history of certificate revocation.

Creating an SSL Certificate Chain

Create Root CA Certificate: The highest authority in the certificate chain is the root certificate authority (CA). It is responsible for issuing intermediate CA certificates and leaf certificates. A root CA certificate is self-signed, meaning it is not signed by any other entity.

Here is an example of the contents of an OpenSSL configuration file (openssl.cnf) that can be used for this guide.

This configuration file sets up a basic certificate authority, with a root CA certificate and an intermediate CA certificate. It sets the default policy to match the country name, state or province name, organization name, and common name of the certificate. The basic constraints section specifies that the leaf certificate should not be used as a certificate authority, and the subject key identifier and authority key identifier extensions are used to link the certificate to its corresponding private key and the issuing CA certificate.

cat << 'EOF' >openssl.cnf
[ ca ]
default_ca = CA_default

[ CA_default ]
dir = .
certs = $dir
new_certs_dir = $dir/newcerts
database = $dir/index
serial = $dir/serial
crlnumber = $dir/crlnumber
crl_dir = $dir/crl
crl = $dir/intermediateCA.crl
crl_extensions = crl_ext

unique_subject = no

certificate = $dir/intermediateCA.pem
private_key = $dir/intermediateCA.key

x509_extensions = usr_cert

default_crl_days = 7
default_days = 365
default_md = sha256

policy = policy_match

[ policy_match ]
commonName = supplied
countryName = optional
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
emailAddress = optional

[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
string_mask = utf8only
req_extensions = v3_req

[ req_distinguished_name ]
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
commonName_default = 

[ v3_ca ]
subjectKeyIdentifier = hash
basicConstraints = CA:true
authorityKeyIdentifier = keyid:always,issuer:always
keyUsage = cRLSign, keyCertSign

[ v3_req ]
basicConstraints = CA:false
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ usr_cert ]
subjectKeyIdentifier = hash
basicConstraints = CA:false
authorityKeyIdentifier = keyid:always,issuer:always

[ crl_ext ]


And with the following set of commands we are creating the self-signed root CA.

# create required file structure
mkdir -p newcerts
touch index crlnumber
echo 01 >serial
echo 1000 >crlnumber

# generate root ca private key
openssl genrsa -out rootCA.key 4096

# self-sign
openssl req -config openssl.cnf -new -x509 -days 18250 -subj "/CN=Test Root CA" -key rootCA.key -out rootCA.pem

Create Intermediate CA Certificate: An intermediate CA is a trusted third party that signs leaf certificates on behalf of the root CA. This helps to reduce the risk of the root CA being compromised.

# generate intermediate ca private key
openssl genrsa -out intermediateCA.key 4096

# create signing request for the root ca
openssl req -config openssl.cnf -new -subj "/CN=Test Sub CA" -key intermediateCA.key -out intermediateCA.csr

# sign the request, using the root ca
openssl ca -config openssl.cnf -batch -extensions v3_ca -days 1825 -in intermediateCA.csr -out intermediateCA.pem -keyfile rootCA.key -cert rootCA.pem

Create Leaf Certificate: The leaf certificate is the actual certificate used by the server to secure communication. It is issued by the intermediate CA and contains information about the domain name, public key, and signature.

# generate leaf certificate private key
openssl genrsa -out leaf.key 4096

# create signing request for intermediate ca
openssl req -config openssl.cnf -new -subj "/CN=Test Server" -key leaf.key -out leaf.csr

# sign the request, using the intermediate ca
openssl ca -config openssl.cnf -batch -in leaf.csr -out leaf.pem

Revoke Leaf Certificate

If a leaf certificate is compromised, it must be revoked. The process of revoking a certificate involves the root CA adding the certificate to a Certificate Revocation List (CRL) or publishing the revocation information in an Online Certificate Status Protocol (OCSP) response.

# revoke the leaf certificate
openssl ca -config openssl.cnf -revoke leaf.pem

# update the crl of the intermediate ca (the issuer)
openssl ca -config openssl.cnf -gencrl -out intermediateCA.crl

History of Certificate Revocation

In the early days of SSL certificates, CRLs were used as the primary method for revoking certificates. However, CRLs had several limitations, such as the large size of the lists, the difficulty in updating them, and the delay in propagating updates to clients. As a result, OCSP was developed as a more efficient way to check the revocation status of certificates. Today, both CRLs and OCSP are used to verify the revocation status of certificates.

Trust side of thigns

Involved Parties

The SSL certificate chain involves several parties, including the root CA, the intermediate CA, the leaf certificate owner, and the client that is connecting to the server.

Basic Requirements for a CA to be Publically Trusted

  1. Operational security: The root CA must have strict security measures in place to protect its key pairs and infrastructure.
  2. Transparency: The root CA must be transparent about its policies and practices for issuing, managing, and revoking certificates.
  3. Financial stability: The root CA must be financially stable to ensure it can continue to operate and provide support for its customers.

Current issues in the Trust Model

  1. Many trusted CA's: The trust model relies on several root CAs, each is able to certify any domain name, e-mail address, document, etc.
  2. Human error: Mistakes made by root CAs or intermediate CAs can compromise the security of the entire internet, which relies on this trust hierarchy.
  3. Vulnerability to hacking: The root CAs hold the keys to the entire certificate chain, making them a high-value target for hackers and state actors.


The SSL certificate chain is a complex system that involves several parties and fundamentally relies on trust. While the trust model, as it's implemented today, has some issues, it remains an essential component of secure communication on the internet. By understanding how the certificate chain works, you can take steps to protect your online assets and improve the security of your systems.

SSL Chain explained by an AI like a stoned surfer bro