Bookmark and Share

Recent Posts

Revealing the Obvious in OpenSSL

January 2, 2018

I’ve always felt that I understood the process of using OpenSSL for self-signed certificates and signing my own certificates—almost. Many times I have used a search engine to read up on “build your own ca server” and always I have not felt “this is it!” I did the same again today and, generally speaking, the results were the same: Create a self-signed certificate and use this to sign certificates.

There was an exception—not a blow-by-blow tutorial but the core steps. And the important change from most bloggers is the discussion of intermediate certificates used for signing. I highly recommend this article. 

The Mystery of OpenSSL, SSL/TLS
While I understand the basics, there was always an element of “But why is this working?” Or, on less fortunate days, the element was “Why isn't this working?” The core mystery for me wasn’t how certificates were made or signed, but rather how OpenSSL verified certificates. What is a Root CA and why and how does my system know about them? Short answer: I read over the obvious because I practiced self-signed certificates rather than becoming my own CA.
 I should hit myself—the answer is SO obvious.
Certificates are verified when a RootCA—which verifies the certificate chain—is found. I have known for a long time that there are arguments that can be supplied to openssl commands. The first arguments to look at are capath and cafile (or CApath and CAfile, respectively). Obviously, applications can use their own definitions. For example, I package curl using --with-ca-bundle=/var/ssl/cacert.pem that curl and libcurl then use, by default, for CAfile.
 I did bang my head against the wall about the not so obvious.
What does OpenSSL, or better libssl, use as its defaults? What I read on the web and what I tried on AIX never seemed to work. Why was OpenSSL not verifying anything? On AIX, it just didn’t find anything, e.g., the command “openssl verify certificate.pem” just failed. OpenSSL didn’t attempt to open any default locations for certificates that could supply the “chain of trust” resolution. In other words, even though OpenSSL discusses these defaults, by default these 'defaults' aren’t used. It’s better to say that there aren’t any defaults defined by OpenSSL.
OpenSSL defaults are provided (if any) by the “provider.” And in the case of IBM and AIX, it seems the only convention is to use the directory /var/ssl to store OpenSSL related information. Other than that convention IBM AIX has no comment. So, without an additional argument such as --capath or --cafile “openssl verify ...” never had a way to locate a store of CA certificates that could be used to verify a “simple certificate,” unlike many Linux distributions that seem to build and package OpenSSL with a default CApath and/or CAfile. 
In Closing
In the coming weeks I am going to be working on my own series of blogs both here and on (and eventually as Rather than continually make self-signed certificates for each server, I’ll act as my own CA. See the article above for the basic steps I'll be following.

Posted January 2, 2018| Permalink

Post a Comment

Note: Comments are moderated and will not appear until approved

comments powered by Disqus