OpenSSL Cheat Sheet
Introduction
When working with certificates, we often have to search for which command to use.
This document aims to be a comprehensive collection of common operations in OpenSSL.
This is not a how-to or guide, the intended audience is experienced with certificates,
but has trouble remembering the commands.
Requesting a certificate
Create a configuration file, I usually call them conf-fqdn
.cfg
, with the following contents:
[ req ]
prompt = no
encrypt_key = no
distinguished_name = dn
utf8 = yes
req_extensions = v3_req
# If you really must, pick one from `openssl list-message-digest-algorithms`
# If you leave this commented out, the newest version of openssl should have
# a good default.
# WARNING: If you use an operating system that releases packages with a large delay
# (aka Debian), you must set these explicit, as the defaults may be horribly outdated.
#default_md = SHA256
#default_bits = 2048
[ v3_req ]
subjectAltName = @alt_names
[ dn ]
C = NO
O = fyrkat
CN = fqdn
[alt_names]
DNS.0 = fqdn
DNS.1 = fqdn1
DNS.2 = fqdn2
Then run the following command:
openssl req -new -config conf-fqdn
.cfg -keyout key-fqdn
.pem -out req-fqdn
.pem
Now you can send req-fqdn
.pem
to your CA for signing. Never send the key file to anyone else, it's top secret. The other files you can send to anyone in the world without it being a problem.
Signing the CSR yourself
Can't wait for the CA and want to use the certificate as self-signed certificate while you wait?
openssl x509 -req -days 30
-in req-fqdn
.pem -signkey key-fqdn
.pem -out cert-fqdn
.pem
Verifying a file
Verifying a signed certificate (including self-signed)
openssl x509 -text -noout -in cert.pem
Verifying a certificate request (CSR)
openssl req -noout -text -verify -in cert.pem
OpenSSL can combine a private key, certificate and chain to a .p12 file,
which some servers require. The chain is optional, just leave out the -certfile ca.pem
part.
openssl pkcs12 -export -inkey key.pem
-in cert.pem
-certfile ca.pem
-out bundle.p12
Different servers have different requirements on which files they need.
Some servers must have key, certificate and chain in different files,
some merge all or some of these in one file. Always use the files that the
server you are configuring requires, and when you must put multiple items
in one file use this ordering (leaving out all that should go in another file):
- The private key
- The certificate
- The chain, excluding the top root certificate
The chain should always start with the CA that signed the certificate,
then the CA that signed that CA and so forth. The last CA must not be included,
because it must already be present in the trust store.