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:
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.
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 ] authorityKeyIdentifier=keyid:always EOF
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
# 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
# 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
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
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.
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.
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.