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.
openssl req -x509 -days 365 -newkey rsa:1024 -keyout <CA-key> -out <CA-cert> -- from isakmpd(8)
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..
[ ca ] default_ca = CAname [ CAname ] database = /etc/ssl/ca.db.index crl = /etc/ssl/ca-crl.pem certificate = /etc/ssl/ca.crt private_key = /etc/ssl/private/ca.key default_md = md5 default_days = 365 default_crl_days = 30
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>
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}"
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:
openssl verify -CAfile <CA-file> -crl_check -verbose -CApath . <certificate>
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!
*) Allow multiple CRLs to exist in an X509_STORE with matching issuer names.
Modify get_crl() to find a valid (unexpired) CRL if possible.
[Steve Henson]
The discussion why is this added so late to this ever-so-great project is left as an excercise for the reader. $ ls *crl* crl1 crl2 $ ls -la `openssl x509 -in ca.crt -noout -hash`.r* lrwxr-xr-x 1 martin wheel 8 Jun 22 21:14 372e1eab.r0@ -> blem.crl lrwxr-xr-x 1 martin wheel 4 Jun 22 20:49 372e1eab.r1@ -> crl1 lrwxr-xr-x 1 martin wheel 4 Jun 22 20:49 372e1eab.r2@ -> crl2 $ openssl verify -CAfile ca.crt -crl_check -verbose -CApath . chrysophilax.steadynet.org.crt chrysophilax.steadynet.org.crt: C = CZ, CN = chrysophilax.steadynet.org error 3 at 0 depth lookup:unable to get certificate CRL $ openssl version OpenSSL 1.0.0a 1 Jun 2010
openssl genrsa [-out <output-private-key-file>] [<bits>] openssl rsa -pubout [-in <private-key-file>] -out <output-public-key-file>
openssl dsaparam -genkey <bits> # or generate parameter file first and use it for faster generation openssl dsa -pubout [-in <private-key-file>] -out <output-public-key-file>
openssl req -new -key <path-to-key> -out <path-to-output> -- from isakmpd(8)
[env {CERTIP=<IP>,CERTFQDN=<dn>}] openssl x509 -req -days 365 -in <csr> -CA <CA-cert> -CAkey <CA-key> -CAcreateserial -out <output> [-extfile /etc/ssl/x509v3.cnf -extensions x509v3_{IPAddr,FQDN}] -- from isakmpd(8)
openssl {s_client,s_server} -- view the manual page and try something. This is real fun compared to the rest of it.
openssl {crl,x509} -in <file> -text [-noout]