OpenSSL cheat sheet

Some information for real dummies

OpenSSL is a library and supportive programs implementing widely used SSL v2/v3 and TLS protocols. Make sure you really understand how these protocols work,
what role does the Certificate Authority have and what are Certificate Signing Requests for, how does certificate revoking work (even before you need it) and how
certificates are signed. What does private and public key look like, what are they for, how to generate them and how to take care of them? What ciphers and hashing functions are widely used and which of them are still secure? What exactly are the X.509 or PKCS standards for? This cheat sheet only concerns about some operations most administrators
need to do, but not so often they'd remember the exact syntax. Don't forget to take a look at the openssl(1) manual page so you get an idea
what commands are there and what each of them provides.
You'll probably end up using only a very few, but it's worth knowing about all of them. It's probably your job, after all. And yes, I know it's boring.

If you are really interested, you can practice attacking a communication that uses invalid or self-signed certificates by utilizing an Man-in-the-Middle attack using some software like
Ettercap. Maybe you'll become one of the very few to realize that 'secure' isn't always secure.

Also, be aware that some software fails to operate with keys larger than 4096 bits. I recall some earlier Microsoft's or Linux IPsec implementations.

CA creation

CRL creation

This is a bit stupid. In fact, it's utterly retarded and completely unnecessary. But you have to use openssl.cnf in order to provide CRLs from the CLI. The following is mandatory in openssl.cnf. You can switch between multiple configurations using
the -config option or between multiple CAs named by [ CAname ] using the -name option in the ca command of the openssl(1) tool..

The default_crl_days depend entirely on whether your boss is a moron. For a stable, reasonable personality, it should be safe to generate CRLs that last longer than one month, as you have probably better things to do than re-creating the same CRLs every month. I don't know why every example on the internet sets this to 30 days, but if you fire an employee on a monthly basis, you may start to wonder why are you doing that. Of course, the big guys like VeriSign may issue their CRLs weekly.

Now you need to create the CRL index file (just by touch(1)ing it for starters) and issue the creation of your first signed CRL using:

openssl ca -gencrl -out <crl-you-specified>

Because of this stupidity, you are required to have CRLs in one location named by hashed names of CA certs. You can create the hash like so:

openssl x509 -noout -hash -in <ca-cert>

And then you create something like /etc/ssl/certs/<hash>.r<number-of-crl>

Revoking a certificate

openssl ca -revoke <cert-to-revoke>
openssl ca -gencrl -out <crl-you-specified>
# ToDo: I'm not entirely sure about which path exactly does which system use. This is more like a general principle.
# Especially the CRL path is system-dependent and VERY hard to find due to lack of documentation
CA_HASH=`openssl x509 -noout -hash -in <ca-cert>`
CRLS_PATH=/etc/ssl/certs
I=0
while test -h "${CRLS_PATH}/${CA_HASH}.r${I}"; do
I=$((${I}+1))
done
while test ${I} -gt 0; do
mv "${CRLS_PATH}/${CA_HASH}.r$((${I}-1))" "${CRLS_PATH}/${CA_HASH}.r${I}"
I=$((${I}-1))
done
ln -sf <crl-you-specified> "${CRLS_PATH}/${CA_HASH}.r${I}"

Verifying a certificate

The relatively easy

openssl verify <certificate-file>

gets complicated by the fact that you must have your openssl.cnf set up properly, or use -config. Even though, you might very often need to say things twice, and it will look like this:

Does anyone know, what should happen with multiple v1 CRLs (without a reason set) and a revoked cert brought back to life? Because even as this is a critical part of the whole system, there's NO DOCUMENTATION AT ALL!