Home Books Training Newsletter Resources
Sign up Log in
book cover

OpenSSL Cookbook  3rd Edition

The definitive guide to using the OpenSSL command line for configuration and testing. Topics covered in this book include key and certificate management, server configuration, a step by step guide to creating a private CA, and testing of online services. Written by Ivan Ristić.


2.3 Certificate Verification

Just because you are able to connect to a TLS server, that doesn’t mean that the service is configured correctly, even if the server supports all the right protocols and cipher suites. It is equally important that the configured certificate matches the correct DNS names.

By default, the s_client tool reports but otherwise ignores certificate issues. Further, before you begin to trust its judgment you need to be confident that it can recognize a valid certificate when it sees one. This is especially true when you’re using a custom-compiled binary.

In the example from the previous section, the verification status code (shown on the penultimate line) was 0, which means that the verification has been successful. If you’re connecting to a server that has a valid public certificate but you see status 20 instead, that probably means that trusted roots haven’t been correctly configured:

Verify return code: 20 (unable to get local issuer certificate)

At this point, if you don’t wish to fix your OpenSSL installation, you can instead use the -CApath switch to point to the location where the roots are kept. For example:

$ openssl s_client -connect www.feistyduck.com:443 -CApath /etc/ssl/certs/

If you instead have a single file with the roots in it, use the -CAfile switch:

$ openssl s_client -connect www.feistyduck.com:443 \
-CAfile /etc/ssl/certs/ca-certificates.crt

Even if you get a successful status code at this point, that doesn’t mean that the certificate is correctly configured. That’s because the s_client tool doesn’t check that the certificate is correct for the given hostname; you have to tell it to do that manually and tell it which hostname to use:

$ openssl s_client -connect www.feistyduck.com:443 -verify_hostname www.feistyduck.com

If there is a mismatch, you might see status code 62:

Verify return code: 62 (Hostname mismatch)

Otherwise, you’ll see the familiar status code 0. In the rare instance that you need to verify a certificate that has been issued for an IP address instead of a hostname, you’ll need to use the -verify_ip switch for the verification.

< Prev
^ Table of Contents
Next >
THE FINEST IN TLS
AND PKI EDUCATION
@feistyduck

Books

  • Bulletproof TLS and PKI
  • ModSecurity Handbook
  • OpenSSL Cookbook

Training

  • Practical TLS and PKI

Resources

  • Bulletproof TLS Newsletter
  • SSL/TLS and PKI History
  • Archived Books

Company

  • Support
  • Website Terms of Use
  • Terms and Conditions
  • Privacy Policy
  • About Us