Verifying and testing newly issued certificates

Nothing is more embarrassing than when an SSL/TSL certificate doesn't have the correct values or isn't delivered correctly, and as a result, users—especially mail servers and mail clients—start complaining. Therefore, you can verify the certificate immediately after it's been created. The openssl command is primarily used for this.

Local tests

All certificate details are displayed here.

~# openssl x509 -in /etc/letsencrypt/live/mail.example.com/fullchain.pem -text -noout

This shows the domain (subject) and issuer (e.g., Let's Encrypt) for which the certificate was issued. It also shows its validity and the alternative domain names (SANs) for which it is valid. Furthermore, the command provides information about the public key and the extensions used.

If only the expiration date is of interest, then this variant helps

~# openssl x509 -enddate -noout -in /etc/letsencrypt/live/mail.example.com/fullchain.pem

Checking the chain, i.e. whether all certificates are included in the file, is done with

~# awk 'BEGIN {c=0;} /BEGIN CERT/{c++} END{print c}' /etc/letsencrypt/live/mail.example.com/fullchain.pem
~# 2

Then you can use the following command to make sure that the certificate and the private key match

~# openssl x509 -noout -pubkey -in /etc/letsencrypt/live/mail.example.com/fullchain.pem | openssl pkey -pubin -outform DER | sha256sum
~# openssl pkey -in /etc/letsencrypt/live/mail.example.com/privkey.pem -pubout -outform DER | sha256sum

The result must be identical both times. And since Let's Encrypt uses ECDSA certificates, this is the correct command for these certificates.

Testing from the client perspective

It doesn't help; you also want to know how the clients (mail clients, web browsers) receive the certificate. This tests via STARTTLS whether the mail server is delivering the correct certificate and establishing a connection.

~# openssl s_client -connect mail.example.com:25 -starttls smtp

For the IMAPs server Dovecot, test as follows.

~# openssl s_client -connect mail.example.com:993

For POP3S (POP3 Secure) you test as follows.

~# openssl s_client -connect mail.example.com:995

If you are interested in the web server output via HTTPs, then this is the right option.

~# openssl s_client -connect mail.example.com:443

In both cases, it is checked 

• whether the TLS handshake is successful.
• which certificate the server sends.
• whether the certificate chain is complete.
• for possible errors (e.g. self-signed, untrusted, expired).

Validation of certificate and hostname

This allows the certificate to be validated against the hostname.

~# openssl s_client -connect mail.example.com:443 -servername mail.example.com

The -servername option is important for servers with SNI (Server Name Indication), i.e., web servers with multiple domains on the same IP address. A positive result is achieved if the message "Verify return code: 0 (ok)" appears in the output.

Proof of complete chain (CA Chain)

To check whether all intermediate certificates are sent, you can use this command.

~# openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

At least two certificates should be displayed:

• The domain certificate itself.
• And the Let's Encrypt intermediate certificate.

View certificate expiration date remotely

If you just want to know when the HTTPS certificate will expire, this will help.

~# echo | openssl s_client -connect mail.example.com:443 -servername mail.example.com 2>/dev/null | openssl x509 -noout -dates

It always makes sense to test clients in this way, since software products from different providers can behave differently and usually spit out meaningless error messages.