How to check certificate integrity and verification results with openssl command/option explanation

Hello everyone.
I work in the System Solutions Department, where waking up in the morning is as painful as the end of the world.

This is the second article on how to check SSL certificates using the openssl command, following the article below.
In the previous article, we focused on checking the "expiration date", which is the most important thing to know about certificates.

How to check the expiration date of a certificate using openssl command/option explanation

 

When issuing a certificate, whether new or renewed, it is important to check its integrity.
1 point about how to check "consistency" using openssl command

After applying the certificate, it is better to check whether the certificate has been successfully "verified" at the certificate authority, so
1 point for the explanation of how to use the openssl command to check whether there is a problem with "verification"

This article focuses on the above two points,
``explaining the methods and options for checking certificate integrity and verification results using the openssl command'' and `
`why can you check this method?''
We will send it to you in the style of "Explanation"

The article's stance is to provide a simple explanation for those who are not familiar with detailed confirmation.

Execution environment

• ●Linux environment
  OS: AlmaLinux release 8.5 (WSL2 environment)
  Shell:Bash
  OpenSSL 1.1.1k FIPS 25 Mar 2021
• ●Windows environment
  OS: Windows11 Pro (version: 22H2)
  Change language setting to Japanese

Preface: Flow of certificate installation

1. When creating a certificate, first create an RSA private key.
2. Create a certificate signing request (CSR) containing the corresponding public key from the private key.
3. by sending the CSR to a certification authority (the owner of the intermediate certificate) and
   having it digitally signed using the certification authority's private key.
4. 
   Completed by installing a total of three items in the target environment (LB, server, etc.): "certificate", "certificate authority certificate (intermediate certificate)", and "private key" that are valid with a digital signature *1

 

*1. In Apache 2.4.8 and later environments, the SSLCertificateChainFile directive that specifies an intermediate CA has been abolished.
Therefore, when applying for a certificate, it is basic to apply for a format that combines the "certificate" and "certificate authority certificate (intermediate CA)" into one.

 

Regarding confirmation of “deadline”, “consistency” and “verification results”

1. before installing and loading certificates ,
   it is necessary to check their "expiration date" (certificate) and " integrity" (common to all three files)
2. Furthermore, after installation,
   it is necessary to check the "verification results" to see is established is this article.

The reason for checking is that if you install the wrong one, it will naturally not function as a certificate.
When this happens, modern browsers will display a warning and result in a site where users may leave the site.

 

● Regarding extensions

◯Extensions used in this article

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

Check "integrity" using openssl command

Sorry to keep you waiting, here's how to check the main issue.
We use the openssl command to check the integrity.

The confirmation methods for "certificates and intermediate certificates" and "certificates and private keys" are different, but
both are performed during installation, so they are executed in the production environment.

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

Display the hash of the certificate's "issuer" (= issuer) information with the issuer_hash option

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

Display hash of “subject” information of intermediate certificate with subject_hash option

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

At this time, you can confirm that they are consistent

 

x509

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

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

-in

Use this option because you need to specify the name of the certificate to load.

-issuer_hash

Displays the hashed issuer information written in the certificate.

-subject_hash

Displays a hashed version of the subject information listed in the certificate.

 

●Why can consistency be checked between different items “issuer_hash” and “subject_hash”?

This is because the information points to the same thing, just with different item names.

The "issuer" of a certificate is the certificate authority.

The "subject" of an intermediate certificate...the subject is the certification authority.

that's right. In other words,
it was checked whether the ``Certificate Authority that issued the certificate'' and the ``Certificate Authority that owned 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 problem.

 

●For Apache2.4.8 or later

The SSLCertificateChainFile directive has been deprecated in Apache 2.4.8 and later environments.

Therefore, in Apache conf,
a single certificate is specified that is a combination of "certificate" and "certificate authority certificate (intermediate CA)".

When you apply for a certificate,
you will be issued a combined certificate for Apache 2.4.8 or later, so there is basically no need to confirm it.

 

*Exception: If your environment is Apache 2.4.8 or later, but certificates have been issued in different conventional formats, you
will have to manually combine the certificates, but before doing so, run this as a precautionary check. I will.

How to check the “integrity” of a certificate and private key

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

Use the openssl x509 command.

Display the certificate modulus using the modulus option.
At this time, it is easier to compare by converting it to a short hash value using md5sum.

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

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

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

At this time, you can confirm that they are consistent

 

x509 -modulus

The modulus value included in the certificate is output as an option of the subcommand "x509".

rsa

When handling RSA keys, use the subcommand ``rsa'' of the ``openssl'' command.

rsa -modulus

This option of the subcommand "rsa" outputs the modulus value included in the key.

| md5sum

This is a command that calculates using the hash function "MD5", and this time we will hash the modulus information passed through the pipe.

 

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

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

Since the explanation will be huge, I will give a rough explanation, but in the RSA encryption method,

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

There are two types of numbers, and
these numbers are used to perform calculations (digital signature and signature verification in the case of HTTPS).

 

is that the private key also has 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 (=consistent).

 

●Since the certificate is not a public key, why can you output modulus?

This is because a certificate has a built-in public key.

Using the public key contained in this certificate, we will begin the steps to perform encrypted communication using HTTPS.

Since a CSR is created from a private key with a single command, it is difficult to notice during operation, but the mechanism is that a CSR (& certificate) contains a public key.

*This article is only a confirmation method, so we omit a fundamental explanation.

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

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

In the previous article, we used openssl s_client to connect and check the contents (expiration date) of the certificate obtained at that time.

 

This time, we will use the normal usage method of ``establishing a connection and outputting a log of 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

Displays a list of certificates sent from the server using the openssl command's subcommand "s_client" option for communicating via SSL/TLS.

Even if you don't use this option, the "verify return code" check below will be displayed, but I use it because it increases the amount of information about the certificate.

Points to check

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

verify return code

A status code indicating the verification status.

- There is no problem if "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, ``21 (unable to verify the first certificate)'' (translation: Unable to verify the first certificate)
indicates that the problem is probably with the intermediate certificate, which is the first certificate traced from the server certificate. .

There are other options such as "10 (Certificate has expired)" (translation: The certificate has expired), which
is very useful when looking for problems because it displays the verification details according to the code.

depth

It shows the hierarchy of certificates, with
0 being the server certificate, 1 being the intermediate certificate, and 2 being the root certificate.

・If "depth" is the correct sequential number of "2", "1", and "0", there is no problem with the flow of the certificate.

However , if all are "0", there is a problem.

This means that the hierarchical structure is not created (= the certificate chain is not established), and
it can be inferred that there is probably a problem with the intermediate certificate.

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

 

“Misapplication of intermediate certificates” to be careful of

I think there is generally no problem if you check the "integrity" of the certificate and intermediate certificate before applying it, but
with Apache 2.4.8 or later, the intermediate certificate is missing because it has been unified. There is a growing possibility that it will be applied.

●It becomes a troublesome situation that you don't notice right away.

This "missing intermediate certificate" situation is extremely troublesome.

In the case of a PC browser, the `` function to supplement intermediate certificates'' often works and ``the site can be viewed

On the other hand, with smartphone browsers, errors often occur because there is no intermediary certificate complementation function, making it difficult to isolate the cause.

There is no problem even if you check the "expiration date" and "domain name" that are mainly checked in the certificate, but
since the site can be viewed on a PC, this is a very troublesome case where the problem is not immediately noticed.

 

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

If "There is no problem with the certificate, but something is wrong with the smartphone" or "There is an error even though there is no problem with the certificate itself"
, use the above command to check if the root certificate and intermediate certificate are functioning without any problems. It would be a good idea to check it out first.

lastly

The certificate confirmation method is very often used in business, so it is very useful to remember it.

However, I think there are some parts that are difficult to understand if you don't know how certificates and SSL/TLS work, so
I think you can deepen your understanding by learning about the system separately.

I hope this article provides some useful knowledge to those who read it.

Reference materials

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

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