OpenSSL cheat sheet

Cap

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

openssl req -x509 -days 365 -newkey rsa:1024 -nodes -keyout <CA-key> -out <CA-cert> -- from isakmpd(8)

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..

[ 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>

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:

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!

RSA key pair generation

openssl genrsa [-out <output-private-key-file>] [<bits>]
openssl rsa -pubout [-in <private-key-file>] -out <output-public-key-file>

DSA key pair generation

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>

CSR creation (at host)

openssl req -new -key <path-to-key> -out <path-to-output> -- from isakmpd(8)

CSR signing (at CA)

[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)

How to interactively communicate using SSL/TLS?

openssl {s_client,s_server} -- view the manual page and try something. This is real fun compared to the rest of it.

Displaying stuff

openssl {crl,x509} -in <file> -text [-noout]

other information? try this: http://www.madboa.com/geek/openssl/
want to develop something that uses OpenSSL? you should read this article before you attempt to do something - it will most likely save you significant amount of time
(will be) Powered by Django (one day) | http://www.potazmo.cz/ | even design by Martin Pelikán
Truhlářství Veselský - Kubík
Němčina - Lena Lišková