Create Self-Signed Certificate

From Postmaster Administration Wiki
Jump to: navigation, search

TLS and SSL require the use of either commercial or self-signed server certificates by which a server will identify themselves and establish encrypted communications. Commercial certificates are highly recommended for online stores using HTTPS or for applications and services that deal with the public, such as ISP mail services SMTP, POP, IMAP, and web mail using HTTPS. Self-signed certificates are sufficient for development, testing, and/or private in-house applications and services. In either case, an administrator will require a CSR for each host machine to be signed by a certificate authority (CA).

There are essentially two ways to create a self-signed certificate. The first method is simple and quick, but might get messy to manage because each self-signed certificate generates a new private key.

The second, involves creating a private in-house CA that can sign private in-house CSRs. An advantage to this method is that the public root certificate for the in-house CA can be published on a web site for staff and clients to access and add to their list of Root CAs.


Quick'n'Dirty Self-Signed Certificate

To generate a new one-year self-signed certificate for host.example.com. You'll be prompted for several informative questions pertaining to your location and organisation. In particular, the Common Name (CN) field must contain the FQDN of the host for which this certificate will be used.

The Common Name (CN) is the most important field in a certificate. It must contain the DNS host name of the server. So if your inbound mail server is mx.example.net, then your certificate's CN must also be mx.example.net. Otherwise, the public will see warnings about invalid and/or mismatched certificates to host names.

$ openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout host.example.com.pem -out host.example.com.pem

Note that the host.example.com.pem should have file permissions restricting access to the root user or administrator only, since it has an encoded copy of the private key.

If you already have a private key for host.example.com, then you reuse it by replacing -newkey rsa:1024 with -key host.example.com.key. Because the private key is already a separate file, using -keyout will not save a copy and is ignored. Also you can script the answer to the questions with -subj as shown here:

$ openssl req -x509 -nodes -days 365 -key host.example.com.key -out host.example.com.pem \ 
  -subj '/C=CA/ST=Quebec/L=Montreal/O=Example Ltd./OU=IT Dept./CN=host.example.com/emailAddress=support@example.com' 


Create a Private CA

Creating a private certificate authority can be useful if you manage many hosts. Also if you supply clients your private CA root certificate, they can then add it to their list of CA root certificates, in order accept your private host certificates without error.

Setup a CA work space.

# cd /root
# mkdir -p CA/ca.db.certs
# cd CA
# echo 01 >ca.db.serial
# touch ca.db.index

Setup a CA work space (windows)

C:\> mkdir -p CA
C:\> cd CA
C:\CA> mkdir ca.db.certs
C:\CA> echo 01 >ca.db.serial
C:\CA> echo > ca.db.index

Note that ca.db.index needs to be initially empty. Otherwise you get an error:

wrong number of fields on line 1 (looking for field 6, got 1, left)

Next, we create a CA private key and a 10 year root certificate, which is the same as creating a quick'n'dirty certificate described above. The Common Name (CN) field in this instance does not name a host name, instead specify the same value as organisation (O) field.

Create CA private key and root certificate.

# openssl genrsa -out ca.key 4096
# openssl req -new -x509 -days 3660 -key ca.key -out ca.crt
# chmod u=r,go= ca.key


Self-Signed Certificate Using A Private CA

With a private certificate authority, we can now self-sign our own certificate signing requests. If renewing a request for the same certificate, but for a different year, revoke the old certificate first before signing:

Revoke previous certificate for same host.

# openssl ca -config ca.config -revoke host.example.com.crt -key ca.key

Now we can sign the host.example.com.csr.

Sign a CSR using private CA.

# openssl ca -config ca.config -policy policy_anything -in host.example.com.csr -out host.example.com.crt
# openssl verify -CAfile ca.crt host.example.com.crt

You now have a self-signed certificate for host.example.com.crt.

Viewing A Certificate

Some .crt files contain both the human readable certificate information and the Base64-encoded certificate block, so it can be viewed in any text editor. However, if you only have the encoded certificate block, then you can review the contents with:

$ openssl x509 -text -noout -in host.example.com.crt

The most important pieces of information to verify are the expiry date and the CN field.

Create A PEM file.

Some server applications require the host key and certificate as separate files. Others prefer them joined together in a .pem file. In both cases, make sure the .key and/or .pem are read-only by the root user or administrator.

$ cat host.example.com.key host.example.com.crt >host.example.com.pem
$ chmod u=r,go= host.example.com.pem


References