How to check certificate integrity and verification results with the openssl command and options

Hello everyone.
This is Naka from the Systems Solutions Department, and I find waking up in the morning to be the end of the world.

This article is the second in a series on checking SSL certificates using the openssl command, following the previous article.
The previous article focused on checking the "expiration date," which is probably the most important thing to consider when it comes to certificates.

How to check the certificate expiration date using the openssl command and options

 

When issuing a certificate, whether it's a "new" or "renewal," verifying its "integrity" is crucial.
Here's one explanation of how to verify "integrity" using the openssl command.

After applying the certificate, it's also a good idea to check if the certificate has been successfully "verified" by the Certificate Authority. Therefore,
I will explain how to check for any problems with "verification" using the openssl command.

This article will focus on the two points mentioned above,
explaining "how to check certificate integrity and verification results using openssl commands and the available options" and
"why these methods work
.

The stance of the article is to provide a simple explanation for those who are not familiar with the details of how to check

Execution environment

• ●Linux environment
  OS: AlmaLinux release 8.5 (WSL2 environment)
  Shell:Bash
  OpenSSL 1.1.1k FIPS 25 Mar 2021
• ●Windows Environment
  OS: Windows 11 Pro (Version: 22H2)
  Language setting changed to Japanese

Introduction: Certificate installation process

1. When creating a certificate, you first create an RSA private key
2. Create a Certificate Signing Request (CSR) from your private key, which contains the corresponding public key
3. A Certificate Signing Request (CSR) is sent to a Certificate Authority (the owner of the intermediate certificate), and
   the document digitally signed by the Certificate Authority using its private key becomes a "certificate."
4. —a "certificate" with digital signature validity, a "certificate authority certificate (intermediate certificate)," and a "private key"—in
   the target environment (LB, server, etc.). *1

 

*1. In Apache 2.4.8 and later environments, the SSLCertificateChainFile directive, which specifies the intermediate CA, has been deprecated.
Therefore, when applying for a certificate, it is standard practice to apply for a format in which the "certificate" and the "certificate authority certificate (intermediate CA)" are combined into a single document.

 

Regarding confirmation of "Deadline," "Consistency," and "Verification Results"

1. the certificatesbefore installing and loading,
   their"expiration date"(certificate) and "consistency"(common to all three files)to verifyit is necessary
2. Furthermore, after installation, it is necessary to check the "verification results" to see if the certificate has been verified and authenticated correctly (i.e., if the certificate chain has been established)
   This."integrity" and "verification resultsarticle explains how to check

The reason for checking is that if you install an incorrect certificate, it obviously won't function.
In that case, modern browsers will display a warning, which could cause users to leave the site.

 

●About file extensions

◯Extensions used in this article

• Certificate (.crt)
• Intermediate CA certificate (=intermediate certificate) (.ca)
• Private key (.key)

Check the "integrity" using the openssl command

Sorry for the wait, now let's get to the main topic: how to verify the integrity.
We'll use the familiar openssl command to check for integrity.

The verification methods for "certificates and intermediate certificates" and "certificates and private keys" differ, but
both are performed during installation and are therefore executed in the production environment.

How to check the integrity of a certificate and an intermediate certificate (= intermediate CA certificate)

issuer_hash option displays a hash of the certificate's "issuer" information

openssl x509 -issuer_hash -noout -in example.com.crt

The subject_hash option displays a hash of the intermediate certificate's "subject" information

openssl x509 -subject_hash -noout -in example.com.ca

In this case,if the two values ​​are exactly the same, consistencycan be confirmed.

 

x509

When dealing with SSL certificates, use the "x509" subcommand of the "openssl" command

*"X.509" is the name of the standard format for public key certificates, so it is easy to remember if you associate it with something

-in

This option is used because you need to specify the name of the certificate to load

-issuer_hash

Displays a hash of the issuer information in the certificate

-subject_hash

Displays hashed subject information in the certificate

 

●Why can consistency be confirmed between items with different "issuer_hash" and "subject_hash"?

This is because the information ultimately refers to the same thing, just with different item names

The "issuer" of a certificate is the certification authority

The "subject" of an intermediate certificate refers to the certification authority

That's right. In other words,
they were checking whether the "certificate authority that issued the certificate" and the "certificate authority that owns the intermediate certificate" were the same.

If these two hash values ​​match, it can be said that the "integrity of the certificate and intermediate certificate" has been confirmed without any problems

 

For Apache 2.4.8 or later

In environments with Apache 2.4.8 or later, the SSLCertificateChainFile directive has been deprecated

Therefore, in the Apache configuration file,
a single certificate is specified that combines the "certificate" and the "certificate authority certificate (intermediate CA)".

When applying for a certificate,
you will be issued a single combined certificate for Apache 2.4.8 and later, so no verification is generally required.

 

*Exception: If you are using an Apache 2.4.8 or later environment but the certificates were issued in separate, older formats, you
will need to manually combine the certificates. However, this is performed as a precautionary check before doing so.

How to check the "integrity" of a certificate and private key

The "consistency" between a certificate and a private key
which is information held by both, ismodulus,"is verified by checking whether

Use the openssl x509 command

The modulus option displays the certificate's modulus;
converting it to a short hash value using md5sum makes comparison easier.

openssl x509 -noout -modulus -in example.com.crt | md5sum

The modulus option of the openssl rsa command displays the modulus of the private key, and
similarly, md5sum converts it to a short-text hash value.

openssl rsa -noout -modulus -in example.com.key | md5sum

In this case,if the two values ​​are exactly the same, consistencycan be confirmed.

 

x509 -modulus

The subcommand "x509" option outputs the modulus value contained in the certificate

rsa

When working with RSA keys, use the "rsa" subcommand of the "openssl" command

rsa -modulus

This is an option for the subcommand "rsa" that outputs the modulus value contained in the key

| md5sum

This is a command that performs calculations using the hash function "MD5," and in this case it hashes the modulus information passed via a pipe

 

●Why can consistency be confirmed if the "modulus" is the same value?

This modulus option displays the "RSA modules," which are one of the numbers used in the RSA encryption format

The explanation is too long to explain, so I will give a rough explanation. In the RSA encryption method,

• A number that only the private key possesses
• A number that also contains a public key (RSA module included here)

There are two types of values, and
calculations (digital signature and signature verification in the case of HTTPS) are performed using these values.

 

What's important here is that the private key also contains the numerical value of the public key.

In other words, if the RSA module held by both keys is the same, it can be confirmed that the public key and private key are a pair (i.e., they are consistent)

 

●Why can a certificate output a modulus even though it is not a public key?

This is because a certificate is a mechanism that contains a public key

Using the public key embedded in this certificate, we begin the process of encrypting communication via HTTPS

A CSR is created from a private key with a single command, so it is difficult to notice when operating it, but in terms of the system, a CSR (and certificate) contains a public key

*This article is only a confirmation method, so we will not go into detailed explanations of the principles

Check the "verification results" with the certificate authority using the openssl command

This is to check whether the root certificate, intermediate certificate, and certificate are functioning correctly (the certificate chain is established)

In the previous article, we connected using openssl s_client and checked the contents (expiration date) of the certificate obtained at that time

 

This time, we will show you how to use it in the normal way, which is to connect and log the communication status to diagnose the status

$ openssl s_client -connect beyondjapan.com:443 -showcerts < /dev/null CONNECTED(00000003) depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root verify return:1 depth=1 C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3 verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = sni.cloudflaressl.com verify return:1 --- Certificate chain 0 s:C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = sni.cloudflaressl.com i:C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3 -----BEGIN CERTIFICATE------ Omitted -----END CERTIFICATE---- 1 s:C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3 i:C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root -----BEGIN CERTIFICATE---- Omitted -----END CERTIFICATE---- Major omission Verify return code: 0 (ok) --- DONE

-showcerts

This option of the openssl command's subcommand "s_client" for communicating via SSL/TLS displays a list of certificates sent by the server

Even without using this option, the "verify return code" below will still be displayed, but I use it because it increases the amount of information about the certificate

Things to check

What you should check here"Verify return code" and "depth" at the bottom.

verify return code

The status code indicates the validation status

- There is no problem if the "verify return" is "0 (ok)"

However,in other cases, the verification details will be displayed according to the code number in the problem.

For example, if you see "21 (unable to verify the first certificate),"
it likely indicates a problem with the intermediate certificate, which is the first certificate traced back from the server certificate.

Other options include "10 (Certificate has expired)" (translation: The certificate has expired),
and it displays verification details according to the code, which is very useful when looking for problems.

depth

This represents the certificate hierarchy,
with 0 being the server certificate, 1 being the intermediate certificate, and 2 being the root certificate, in that order.

- If "depth" is correctly numbered consecutively as "2", "1", and "0", there is no problem with the certificate flow

However, it is a problem if all values ​​are "0".

This indicates that a hierarchical structure has not been created (i.e., the certificate chain is not established), and it
is highly probable that there is a problem with the intermediate certificate.

In this case, the verify return code will likely be 21

 

Beware of "missing intermediate certificates"

While there shouldn't be any major problems if you verify the "consistency" of the certificate and intermediate certificate before applying them,
with Apache 2.4.8 and later, the unification has increased the likelihood of applying the certificate with the "intermediate certificate missing."

●It can become a troublesome condition that you may not notice right away

This situation, where the intermediate certificate is missing,is extremely troublesome.

On PC browsers, the "intermediate certificate completion function"or "intermediate certificates stored in the cache"you to view the siteoften works,

On the other hand, when using smartphone browsers, errors often occur due to a lack of intermediate certificate completion functionality, making it difficult to isolate the cause

The certificate itself shows no problems, including the "expiration date" and "domain name," and
the site is accessible on a PC, making it a very troublesome case where the problem is "not immediately apparent."

 

In fact, learning about the existence of this case is the main reason I decided to write this article

If you're experiencing issues like "the certificate is fine but only my smartphone is acting strangely" or "the certificate itself is fine but I'm getting an error,"
you should first check if the root certificate and intermediate certificates are functioning correctly using the command above.

lastly

The method of verifying certificates is something that is used very frequently in business, so it is very useful to remember it

However, some parts may be difficult to understand if you are unfamiliar with certificates and the SSL/TLS mechanism, so
learning about the mechanism separately will deepen your understanding.

I hope this article will be of some use to those who read it

Reference materials

The official OpenSSL manual page for openssl-x509
is available at https://www.openssl.org/docs/manmaster/man1/openssl-x509.html

OpenSSL (ArchWiki)
https://wiki.archlinux.jp/index.php/OpenSSL