Desperately Balanced

Using OpenSSL to generate keys and Certificate Signing Requests is easy, unless you want to control extended attributes like Subject Alternative Names. Until recently the only way to do it was to edit the config file being fed to OpenSSL. And in my experience, once you've done that, history is a series of losing the OpenSSL config file you created and having to Google around until you figure it out again.

While trying to figure out how to make this process easier for people I'm working with, I found some clever tricks described on Stack Exchange for feeding the config file in to OpenSSL using Bash Here Documents. The more I played with that, though, the more complex my rewriting of the OpenSSL config file became - until I decided to inline the entire config file to the script, write it on the fly, and use it to make OpenSSL config file options seamlessly available to the command line.

The result, one_genkey, is available on github for you to play with.

Sometimes you want to grab a copy of a server's TLS certificate - usually in order to perform Certificate Pinning. This is an additional security step used to provide additional assurance that the server you're talking to is the correct server (and is not, for example, an imposter using a bogus but legitimately issued certificate).

There are a number of different methods to do so, both from browsers and from the command line. This post documents a couple command line methods; a followup post will go into browser methods.

It should be noted - while we're on the topic - that Certificate Pinning is a controversial step to take, because it breaks things. In the ordinary course of events, when a certificate is replaced with a newer certificate, this change is invisible to the client, because both the old and the new certificate "check out" (in that they're issued by a valid CA, they're within valid dates, they're not on a CRL, etc. etc.). When you start pinning, you lose the ability to adapt when a certificate is replaced in the normal cause of business (expiration, compromise, addition of SAN names to the cert, etc. etc.). So if you're depending on access to a service, but trying to improve security by pinning, be aware that you may be shooting your availability/uptime in the foot, because when the certificate gets replaced by the server's owner your pinning will break the connectivity.
Continue reading "Grabbing a copy of a server's TLS certificate"