I prefer doing things in command line interfaces rather than guis, even when it is not obviously better – as long as it’s not obviously worse. Why? Because anything that can be done in a cli can be trivially automated. The command-line paradigm11 And by extension, the orthodox ui paradigm. What’s that? I’m still planning to write an article on it, but things get in the way. is very powerful that way.
So while tls certificates can usually be checked very easily in your web browser
of choice, I still find it useful to know how to do it in the terminal. The
openssl command is not the most friendly, but it appears I have finally
memorised the incantation. To print the certificate, we need to attempt to
openssl in its client mode.
echo \ | openssl s_client \ -connect two-wrongs.com:443 \ -servername two-wrongs.com
If we additionally want to know expiration dates, we can take the result of the
previous command and pipe it to
openssl again, this time asking it to decode the
echo \ | openssl s_client \ -connect two-wrongs.com:443 \ -servername two-wrongs.com \ | openssl x509 \ -noout \ -dates
So there’s that!
Redirects and Non-http Connections
There are other reasons to prefer doing this through the terminal, though.
If you want to check the certificate for a non-canonical domain, for example,
your web browser tends to redirect you to the canonical domain before you
have a time to look at the certificate. The
openssl client does not follow
redirects, and will simply get the certificate for the domain you ask for.
Another thing of note is that tls is not unique to http. In principle, any
protocol can be used over a tls connection and thus become more secure. The
openssl method will check certificates for any sort of tls connection, while
the web browser tends to be limited to https.
Inventory of Best Practises
Of course, this is fine if you are trying to check basic things such as issuer, what type of certificate it is, or expiration dates.