Wandering Thoughts archives

Making self-signed SSL certificates with OpenSSL

So that I don't have to try to remember it or look it up next time around, here is how to generate a real self-signed SSL certificate with OpenSSL. The basic but incomplete incantation is:

openssl req -x509 -nodes -days <HOWMANY> -keyout <FOO>.key -out <FOO>.crt ...

If you want a merged PEM certificate, just make the -keyout and -out arguments the same thing. The key (or the PEM certificate) must be kept private; the certificate can be world-readable. (This command creates an unencrypted private key, with no password. My opinion is that anyone using encrypted private keys for servers is a masochist.)

To the basic incantation you must add one of two sets of arguments:

• '-newkey rsa:1024'; this will prompt you for information; in order, C, ST, L, O, OU, CN (usually a host name), and the email address. It will eat standard input.
• '-new -config <CONFIGFILE>'; this will take all information from the config file.

(On some systems you can also use '-newkey rsa:1024 -subj <INFO>', where <INFO> lists the CN et al information in a compact form, but this barfs on at least some of my machines. See, for example, here. If you need to specify an email address, its attribute name is 'emailAddress'.)

A configuration file looks like this:

RANDFILE = $ENV::HOME/.rnd

[ req ]
default_bits	= 1024
default_keyfile = privkey.epm
distinguished_name = req_distinguished_name
prompt		= no

[ req_distinguished_name ]
countryName  = CA
stateOrProvinceName = Ontario
localityName = Toronto
organizationName = University of Toronto
organizationalUnitName = CNS
commonName   = utcc.utoronto.ca
emailAddress = spamtrap1@utcc.utoronto.ca 

Naturally I don't recommend that you copy this example literally, unless you really want to generate a self-signed key for our server.

Having created a PEM file (or just having one lying around), you can examine it with 'openssl x509 -inform PEM -text -noout -in <FOO>.pem'. Similar arguments can likely be used for keys and for certificates.

Sidebar: Other references

Here is a discussion about a potential problem with self-signed certificates if you have to renew them. Locally we deal with this problem by generating self-signed certificates with very long expiry times; my current choice is 9999 days.

A good Google search for this seems to be [openssl self-signed certificate]. If you throw in 'making', the top results turn into being mostly about how to make your own Certificate Authority cert and then sign things with that. This is somewhat different from a self-signed certificate, plus is more work.

A little sysadmin twitch

Every system administrator has little twitches, behaviors that strike outside observers as somewhere between odd and superstitious. Sometimes these are just habits, but sometimes they have interesting stories behind them.

One of my twitches is that when I use su, I always type '/bin/su' (or on some irritating systems, '/usr/bin/su'), not plain 'su'. (By now it's a reflex.)

This habit originated in a bit of security advice. The story goes that if you didn't use absolute paths, an intruder who compromised your account could alter your $PATH so that plain 'su' ran a trojan version of su that logged the password somewhere, told you 'bad password', and then cleaned itself away to make future su's work normally.

In my current environment this is mostly superstition, because most of the time I get root access by starting a 'root xterm' (more or less 'xterm -e /bin/su -fg OrangeRed'; the red foreground makes such xterms stand out, avoiding accidents). An attacker who compromised my account could just zap the fvwm2 menu entry for this instead of changing my $PATH.

Still, it's my little twitch. Life wouldn't be quite the same without it.