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

Hello everyone.
I work in the System Solutions Department and wake up feeling like the world is ending.

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

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

 

When issuing a certificate, whether it is a new certificate or a renewal certificate, it is important to check its integrity.
There is one point explaining how to check its integrity using the openssl command.

After applying the certificate, it is a good idea to check whether the certificate has been successfully "verified" by the certification authority. Therefore,
1 point will be awarded for the explanation of how to check whether there are any problems with the "verification" using the openssl command.

This article will focus on the above two points and
will explain the options and methods for checking certificate integrity and verification results using the openssl command,
as well as the reasons why this method can be used to verify the certificate
.

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)
  Change language setting 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. The CSR is sent to the certification authority (owner of the intermediate certificate), and
   once it has been digitally signed with the certification authority's private key, it becomes a "certificate."
4. the "certificate" that has been made valid by the digital signature, the "certificate of the certification authority (intermediate certificate)", and the "private key"
   . *1

 

*1. In environments with Apache 2.4.8 or later, the SSLCertificateChainFile directive for specifying an intermediate CA has been abolished.
Therefore, when applying for a certificate, it is standard practice to apply in a format that combines the "certificate" and "certificate of the certification authority (intermediate CA)" on a single sheet.

 

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

1. When updating certificates you must check
   the "expiration date" (certificate) and " integrity" (common to all three files) before installing and loading
2. Furthermore, after installation, you will need to check the "verification results" to see if the certificate has been verified and correctly authenticated (the so-called certificate chain has been established)
   . This article explains how to check "integrity" and "verification results."

The reason for checking is that if the wrong certificate is installed, it will obviously not function as a certificate.
If this happens, modern browsers will display a warning, which may cause users to abandon 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, but now we come to the main topic of how to check the integrity. We
will use the well-known openssl command to check the integrity.

The verification methods for "certificate and intermediate certificate" and "certificate and private key" are different, 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

At this time, if the two values ​​are exactly the same, you can confirm that they are consistent.

 

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,
it was 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 Apache conf,
a single certificate is specified that combines the "certificate" and the "certificate authority certificate (intermediate CA)."

When you apply for a certificate,
you will be issued a single combined certificate for Apache 2.4.8 or later, so there is generally no need for any verification work.

 

*Exception: If you are using Apache 2.4.8 or later and the certificates have been issued in separate traditional formats, you
will need to manually combine the certificates. However, before doing so, run this as a precautionary check.

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

The "integrity" of a certificate and private key
is determined by checking whether modulus," information held by both, is

Use the openssl x509 command

The modulus option displays the modulus of the certificate.
At this point, converting it into a short hash value using md5sum makes it easier to compare.

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

Use the modulus option of the openssl rsa command to display the modulus of the private key, and
similarly convert it into a short hash value using md5sum.

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

At this time, if the two values ​​are exactly the same, you can confirm that they are consistent.

 

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)

These are the two types of numbers
that are used for calculations (digital signature and signature verification in the case of HTTPS).

 

The important thing to note here is that the private key also contains the numerical value that the public key has .

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 content will be displayed according to the code number in the problem.

For example, if you get "21 (unable to verify the first certificate)," this
likely means there's a problem with the intermediate certificate, which is the first certificate found from the server certificate.

There are other options like "10 (Certificate has expired)" and
they'll show you the validation details along with your code, which can be very useful when trying to find problems.

depth

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

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

However , if all the numbers are "0", that's a problem.

This means that a hierarchical structure has not been created (i.e. the certificate chain has not been established), and it
is highly likely 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"

Generally, there should be no problem if you check the consistency of the certificate and intermediate certificate before applying them, but
with Apache 2.4.8 and later, the certificates have been unified into one, which increases the possibility of applying the certificate without the intermediate certificate.

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

This "missing intermediate certificate" situation is extremely troublesome.

In PC browsers, the " function to supplement intermediate certificates" or "intermediate certificates in the cache" often works, to "view the site

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

in which the main things to check on a certificate, such as the expiration date and domain name, are found to be fine, and
the site can be viewed on a PC, so the problem is not immediately noticed.

 

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

If you are experiencing issues with your certificate but not with your smartphone, or if there is no problem with the certificate itself but an error occurs, it
is a good idea to first use the above command to check whether the root certificate and intermediate certificate are functioning properly.

lastly

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

However, there may be some parts that are difficult to understand if you are not familiar with the mechanisms of certificates and SSL/TLS, so
learning about the mechanisms separately will help you to gain a deeper understanding.

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

Reference materials

Official OpenSSL manual page on openssl-x509:
https://www.openssl.org/docs/manmaster/man1/openssl-x509.html

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