Self Signed SSL certificates

Use self-signed certificates to test single systems, such as a test web server. Self-signed certificates become impractical in any other case. A local CA, while more complex to setup, reduces the number of keys that need to be distributed for verification, and properly replicates a real world certificate environment.

Creation of certificates requires the openssl utility. This command should be part of an OpenSSL installation, though may be installed out of the standard search path in /usr/local/ssl/bin or elsewhere.

$ which openssl
/usr/bin/openssl

1. Generate the Rivest, Shamir and Adleman (RSA) key

OpenSSL can generate a Digital Signature Algorithm (DSA) key (with the gendsa option), though for compatibility RSA keys are most frequently used. Learn more about the genrsa option to openssl.

$ openssl genrsa 1024 > host.key
$ chmod 400 host.key

Modern systems should provide a random device and sufficient entropy for key generation. The data in the host.key file must be protected, as anyone with this information can decrypt traffic encrypted with this key.

2. Create the Certificate

Learn more about the req option to openssl. The -new, -x509 and -nodes arguments are required to create an unencrypted certificate. The -days argument specifies how long the certificate will be valid for.

$ openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert

Questions may be asked to fill out the certificate’s x509 attributes. The answers should be adjusted for the locale:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Washington
Locality Name (eg, city) []:Seattle
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Sial.org
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:mail.example.org
Email Address []:postmaster@example.org

The Common Name field usually must exactly match the hostname of the system the certificate will be used on; otherwise, clients should complain about a certificate to hostname mismatch.

The certificate data in the host.cert file does not need to be protected like the private key file does. In fact, it will likely need to be transferred to all the client systems that need to verify the key of the server being connected to. If this is the case, setup a CA, and distribute the signing certificate to the clients instead of each self-signed certificate.

3. Extract Metadata (Optional)

Optionally, various certificate metadata can be saved for quick reference, for example to verify the key fingerprint. Learn more about the x509 option to openssl.

$ openssl x509 -noout -fingerprint -text <> host.info

4. Combine Key and Certificate Data (Optional)

Some applications may require that the key and certificate data be in a single file. I recommend keeping the key and certificate data separate if possible, as the key data needs to be protected, and the certificate data available to all. Combining the data means the resulting file must be protected like a key file.

$ cat host.cert host.key > host.pem \
&& rm host.key
$ chmod 400 host.pem

The host.cert certificate data will need to be exported to client systems for use in testing.

The openssl.cnf file

Localize the system openssl.cnf to include relevant X509 attributes of the certificate. This will save typing and avoid errors when creating certificates. The location of this file varies by system.

$ grep Name_default /etc/ssl/openssl.cnf
countryName_default = US
stateOrProvinceName_default = Washington
0.organizationName_default = Sial.org
#1.organizationName_default = World Wide Web Pty Ltd
#organizationalUnitName_default =