Manually validating custom certificate chain PEM file
search cancel

Manually validating custom certificate chain PEM file

book

Article ID: 369297

calendar_today

Updated On:

Products

VMware Aria Suite

Issue/Introduction

How to validate each component of a certificate PEM file, assuming that:

  • Certificate chain is in Base64 format
  • The components are assembled in a certificate chain PEM file, though this can also be used on individual certificate files such as Base64 encoded .pem, .cer, .crt files
  • This article aims to provide instructions on what is important to verify when validating the certificate chain
  • You have a Linux based system with openssl installed where you can perform the steps under the resolution below

Environment

  • A custom certificate is generated and signed with certificate authority (CA)
  • Certificate authorities frequently have rules/templates that are configured by the certificate authority administrator
  • Some certificate authorities generate or use existing pre-defined private key when certificates are signed. This may result in failure to apply the certificate on the endpoint. Consult your certificate authority administrator

Resolution

Validating certificate components

Use the command below to output certificate information that is useful to validate certificate components, either on a certificate chain or single certificate files.

awk -F'\n' '
BEGIN { showcert = "openssl x509 -noout -dates -fingerprint -issuer -subject -ext subjectKeyIdentifier,authorityKeyIdentifier,basicConstraints" }
/-----BEGIN CERTIFICATE-----/ {printf "\nCertificate %d: \n", i}
{printf $0"\n" | showcert}
/-----END CERTIFICATE-----/ {close(showcert) i++}' <certificate_file>

Replace <certificate_file> with the name of the certificate chain or single certificate file, without the <> brackets. Ensure sure that you copy all the content in the above box, this is one single command rather than several lines of commands.

 

The following example was created based on a certificate chain that contained the following certificates/key, in the following order:

  1. Server certificate
  2. Server private key
  3. Intermediate certificate
  4. Root certificate
root@localhost [ ~/ca ]# awk -F'\n' '
BEGIN { showcert = "openssl x509 -noout -dates -fingerprint -issuer -subject -ext subjectKeyIdentifier,authorityKeyIdentifier,basicConstraints" }
/-----BEGIN CERTIFICATE-----/ {printf "\nCertificate %d: \n", i}
{printf $0"\n" | showcert}
/-----END CERTIFICATE-----/ {close(showcert) i++}' test.pem
 
Certificate 0:
notBefore=Jun  3 15:57:15 2024 GMT
notAfter=Jun 13 15:57:15 2025 GMT
SHA1 Fingerprint=DC:C1:CA:5C:09:CC:05:3F:AF:47:67:29:E9:5A:DD:FF:30:A7:4D:04
issuer=C = IE, ST = Location, O = ACME, OU = CMBU, CN = Root Sandbox Intermediate CA, emailAddress = [email protected]
subject=C = IE, ST = Location, L = Location, O = ACME, OU = CMBU, CN = web.example.com, emailAddress = [email protected]
X509v3 Basic Constraints:
    CA:FALSE
X509v3 Subject Key Identifier:
    74:C3:28:E6:26:4D:34:03:DD:CD:38:3B:19:64:0F:89:C9:51:FE:F5
X509v3 Authority Key Identifier:
    keyid:1F:16:56:79:13:F6:7F:4A:9F:E9:E8:3B:46:C8:42:A2:6F:54:30:AD
    DirName:/CN=Repro Sandbox CA/C=IE/ST=Location/L=Location/O=ACME/OU=CMBU/[email protected]
    serial:10:00
 
Certificate 1:
notBefore=Jun  3 15:47:05 2024 GMT
notAfter=Jun  1 15:47:05 2034 GMT
SHA1 Fingerprint=AE:9D:8E:E9:AB:FA:DD:6F:65:B4:4A:3D:39:86:1A:43:1A:5B:95:C8
issuer=CN = Repro Sandbox CA, C = IE, ST = Location, L = Location, O = ACME, OU = CMBU, emailAddress = [email protected]
subject=C = IE, ST = Location, O = ACME, OU = CMBU, CN = Root Sandbox Intermediate CA, emailAddress = [email protected]
X509v3 Subject Key Identifier:
    1F:16:56:79:13:F6:7F:4A:9F:E9:E8:3B:46:C8:42:A2:6F:54:30:AD
X509v3 Authority Key Identifier:
    5C:97:A2:91:56:6C:0B:37:1A:41:30:82:6C:27:FC:49:A2:84:24:0F
X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0
 
Certificate 2:
notBefore=Jun  3 15:42:35 2024 GMT
notAfter=May 29 15:42:35 2044 GMT
SHA1 Fingerprint=99:41:FB:3B:BA:3B:BE:88:6E:8A:C3:1C:DF:16:97:12:38:41:F1:9C
issuer=CN = Repro Sandbox CA, C = IE, ST = Location, L = Location, O = ACME, OU = CMBU, emailAddress = [email protected]
subject=CN = Repro Sandbox CA, C = IE, ST = Location, L = Location, O = ACME, OU = CMBU, emailAddress = [email protected]
X509v3 Subject Key Identifier:
    5C:97:A2:91:56:6C:0B:37:1A:41:30:82:6C:27:FC:49:A2:84:24:0F
X509v3 Authority Key Identifier:
    5C:97:A2:91:56:6C:0B:37:1A:41:30:82:6C:27:FC:49:A2:84:24:0F
X509v3 Basic Constraints: critical
    CA:TRUE

How to interpret the output from the example:

  1. Certificate validity
    Review notBefore and notAfter to ensure that certificates in chain are valid, and not expired.

  2. SHA1 Fingerprint (aka Thumbprint)
    For the purpose of this exercise, this value has little to no use. It is included in the command as it can be useful to verify certificates imported on endpoints.

  3. Subject and Issuer
    The only reason to include these is for readability, as they are easier to read than authority/subject key identifiers
    They can also help identify the name of the issuing certificate, for instance if a certificate is missing

  4. X509v3 Authority/Subject Key Identifiers
    These are the most important part to verify that the chain is complete. The values are important to determine the parent/child certificates in the chain
    Also known as: subjectKeyIdentifier and authorityKeyIdentifier

  5. X509v3 Basic Constraints
    This determines if certificate is a root, intermediate, or server/web/endpoint certificate
    For root and intermediate certificate this will be CA:TRUE
    For server/web certificates this will be set to CA:FALSE

 

Root certificate (certificate 2)

  1. Subject and issuer are identical
  2. subjectKeyIdentifier and authorityKeyIdentifier are identical
  3. X509v3 Basic Constraints is CA:TRUE

This is a clear indication that this certificate is a root certificate. When verifying a root certificate look at the subjectKeyIdentifier and authorityKeyIdentifier. If these do not have the same value, that means that this is not a root certificate.

 

Intermediate certificate (certificate 1)

  • Subject is not identical to issuer
  • Issuer is the same as subject in root certificate (certificate 2)
  • subjectKeyIdentifier and authorityKeyIdentifier are not identical
  • authorityKeyIdentifier is identical to subjectKeyIdentifier in root certificate (certificate 2)
  • X509v3 Basic Constraints is CA:TRUE

This indicates that the certificate is an intermediate certificate. It's important to note that for intermediate certificate, the following is expected:

  • X509v3 Basic Constraints is CA:TRUE
  • subjectKeyIdentifier and authorityKeyIdentifier are not identical

Those two alone will indicate whether this certificate is a root or intermediate certificate, depending on whether subjectKeyIdentifier and authorityKeyIdentifier are identical or not.

 

Server/web/endpoint certificate (certificate 0)

  • Subject is not identical to issuer
  • Issuer is the same as subject in intermediate certificate (certificate 1)
  • subjectKeyIdentifier and authorityKeyIdentifier are not identical
  • authorityKeyIdentifier is identical to subjectKeyIdentifier in intermediate certificate (certificate 1)
  • X509v3 Basic Constraints is CA:FALSE

As Basic Constraints is set to CA:FALSE, this indicates that this is a server/web/endpoint certificate, we also see that authorityKeyIdentifier for certificate 0 matches subjectKeyIdentifier for intermediate certificate (certificate 1).

 

Key rules for checking certificate chain:

  • X509v3 Basic Constraint CA:FALSE indicate a server/web/endpoint certificate
  • X509v3 Basic Constraint CA:TRUE indicate a root/intermediate certificate
  • authorityKeyIdentifier matches subjectKeyIdentifier in the parent certificate, except for root certificate where authorityKeyIdentifier and subjectKeyIdentifier are identical, as root certificate is not signed by another certificate.
  • Do not rely on subject and issuer to indicate that the chain is correct. Root and intermediate certificates can be renewed without the subject changing. Always use subjectKeyIdentifier and authorityKeyIdentifier to validate chain, as these values are not retained on certificate renewals

 

 

Validating key with server/web/endpoint certificate

To validate that the key and server certificate matches use these three commands (Linux only, sha256sum command is not available in Windows):

openssl pkey -in <KEY>.key -pubout -outform pem | sha256sum
openssl x509 -in <CERT>.crt|.cer -pubkey -noout -outform pem | sha256sum
openssl req -in <CSR>.csr -pubkey -noout -outform pem | sha256sum

It's highly recommended to validate the KEY, CSR, and CERT files, as some Certificate Authorities may use their own keys to sign the cert, replacing the key that the CSR file was generated with. If this is the case, check with your Certificate Authority administrator on how to extract the key.

The above commands must be issued against the individual certificate, key, and csr files that were generated, rather than the assembled PEM file.

 

Example:

root@localhost [ ~/certtest ]# openssl pkey -in server.key -pubout -outform pem | sha256sum
0dca3acae10c2725e7484e83fe1cf883fe2d2db21b60c23fbf3e8ee1524e3a84  -

root@localhost [ ~/certtest ]# openssl req -in server.csr -pubkey -noout -outform pem |sha256sum
0dca3acae10c2725e7484e83fe1cf883fe2d2db21b60c23fbf3e8ee1524e3a84  -

root@localhost [ ~/certtest ]# openssl x509 -in cert.cer -pubkey -noout -outform pem | sha256sum
0dca3acae10c2725e7484e83fe1cf883fe2d2db21b60c23fbf3e8ee1524e3a84  -

Notice that the SHA256 sum for key, CSR, and certificate matches, which means that the key used with the server/web/endpoint certificate is correct. If these do not match, the incorrect key has been used.

Additional Information

  • Certificates may be provided in multiple files, or in single files
  • File extensions may be .pem, .cer, .crt. It's possible that other file extensions are used.
  • Each certificate is Base64 encoded, this is indicated by the the BEGIN and END lines in the certificate file, as follows:

    -----BEGIN CERTIFICATE-----
    <Base64 encoded certificate>
    -----END CERTIFICATE-----
Powered by Wolken Software