How to check the order of certificates for certificate chain

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux (RHEL)
  • Red Hat OpenShift Container Platform (RHOCP)
  • Certificate Authority (CA) chain

Issue

  • Need a way to check the certificate order for certificate chain.
  • The cluster-wide proxy configuration in OpenShift requires the correct certificate chain in order to proceed.
  • The Secure LDAP configuration in OpenShift requires the correct certificate chain.

Resolution

Correct the order of the certificates in the file (they should be in "descending" order) and check if the order is now correct:

# openssl crl2pkcs7 -nocrl -certfile ca-bundle.crt | openssl pkcs7 -print_certs -noout

subject=/C=US/O=Digicert Inc/OU=www.example.com/CN=*.apps.example.com
issuer=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert SHA2 High Assurance Server CA            <<<<<< 1

subject=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert SHA2 High Assurance Server CA           <<<<<< 1
issuer=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert High Assurance EV Root CA                <<<<<< 2

subject=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert High Assurance EV Root CA               <<<<<< 2
issuer=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert High Assurance EV Root CA

Along with order of the certificates, it's also important for certificates to match Subject Key Identifier (SKID) and Authority Key Identifier (AKID) to complete the chain. Considering a chain of wildcard+intermediateCA+RootCA, the AKID of wildcard certificate must match with SKID of IntermediateCA. Likewise, AKID of IntermediateCA must match to SKID of it's RootCA in the chain.

Root Cause

The most common reason for a certificate deployment to fail is that the intermediate/chain certificates are not in the correct order. Specifically, intermediate certificate files must end with the root certificate, and be in a descending order from the main/server certificate to the root.

Diagnostic Steps

Determine the order of the intermediate files by running the following command:

# openssl crl2pkcs7 -nocrl -certfile ca-bundle.crt | openssl pkcs7 -print_certs -noout
subject=/C=US/O=Digicert Inc/OU=www.example.com/CN=*.apps.example.com
issuer=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert SHA2 High Assurance Server CA              <<<<<< 1

subject=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert High Assurance EV Root CA                 <<<<<< 1
issuer=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert High Assurance EV Root CA                  <<<<<< 2

subject=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert SHA2 High Assurance Server CA             <<<<<< 2
issuer=/C=US/O=DigiCert Inc/OU=www.example.com/CN=DigiCert High Assurance EV Root CA

From the above lines, the content (except the subject/issuer words) of the lines marked with 1 should match, and the lines marked with 2 should match. As it is not the case, the certificate chain in above example is not correct.

Example for checking certificates configured in a configmap in OpenShift Container Platform:

$ oc extract cm/custom-ca -n openshift-config --to=/tmp/ca-bundle.crt
$ openssl crl2pkcs7 -nocrl -certfile /tmp/ca-bundle.crt | openssl pkcs7 -print_certs -noout
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.