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 are in a Base64 format
  • Assembled in a certificate chain PEM file, can also be used on single certificate files such as Base64 encoded .pem, .cer, .crt files individually
  • The article aims to provide instructions on what is important to verify when validating the certificate chain
  • A Linux based system where you can run these commands are in place, and have openssl tools installed to perform the steps under resolution

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 generates, or use existing pre-defined private key when certificates are signed. This may result in failure to apply certificate on endpoint. Consult your certificate authority administrator

Resolution

Validating certificate components

Use command below to output certificate information useful for 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 = Cork, O = VMware, OU = CMBU, CN = Root Sandbox Intermediate CA, emailAddress = [email protected]
subject=C = IE, ST = Cork, L = Cork, O = VMware, 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=Cork/L=Cork/O=VMware/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 = Cork, L = Cork, O = VMware, OU = CMBU, emailAddress = [email protected]
subject=C = IE, ST = Cork, O = VMware, 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 = Cork, L = Cork, O = VMware, OU = CMBU, emailAddress = [email protected]
subject=CN = Repro Sandbox CA, C = IE, ST = Cork, L = Cork, O = VMware, 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. Included in command as this can be useful to verify certificate 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 two commands:

openssl x509 –noout –modulus –in <certificate_file> | openssl md5
openssl rsa –noout –modulus –in <key_file> | openssl md5

Note that it is easiest to validate these prior to assembling a PEM file with certificate chain that includes the private key.

 

If the PEM chain only contains a single key, use the following command to extract the key to a single file:

openssl storeutl -keys <certificate_file> > extracted.key

Replace <certificate_file> with the name of the certificate chain, without the <> brackets.

 

After extracting the key from the chain, or use key file used when assembling PEM chain, run the two commands above against the chain and the extracted key

  • Be aware that when the modulus for the chain is created it will only look at the first certificate in the chain, ensure that the the server/web/endpoint certificate is at the top
  • If root or intermediate certificate is at the top of of the PEM file, consider rearranging the order of the PEM file
root@localhost [ ~/ca ]# openssl x509 –noout –modulus –in extracted.key | openssl md5
x509: Use -help for summary.
MD5(stdin)= d41d8cd98f00b204e9800998ecf8427e
root@localhost [ ~/ca ]# openssl x509 –noout –modulus –in test.pem | openssl md5
x509: Use -help for summary.
MD5(stdin)= d41d8cd98f00b204e9800998ecf8427e

Notice that the MD5 sum for key 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