Creating a web-site certificate: Part 1

Website encryption uses a technique called Secure Socket Layer, SSL. An encryption certificate is necessary for adding SSL support to a web server.

Certificates can be bought from any number of Certificate Authorites (CAs for short). The advantage of buying a certificate from a well-known Certificate Authority is that the certificate is signed by the CA. Web browsers contain a list of known and trusted CAs, so a certificate signed by one of them will be automatically, and silently, accepted by the browser. Somewhere deep inside the configuration menus, most browser have an option to show, and possibly modify, that list. Before buying a certificate, it can be a good idea to check that the CA is trusted by all major browsers.

We can also get a certificate on the cheap, by creating it our selves. Besides price, the advantage is that we can easily add and modify certificates, and experiment freely.

Using a password-protected private key
PDF Image LaTeX source

There are just a few steps involved in creating a website certificate:

  • Create a password-protected encryption key.
  • Optionally create a unprotected version of that key.
  • Create a Certificate Signing Request
  • Create the certificate

Here, we do this using openssl, probably the most widely used tool for all things SSL.

The command lines below have been split over several lines for readability.

$ openssl genrsa -des3
                 -passout env:PASS
                 -out     rsa-private-key-with-password.key

This invocation of the genrsa subcommand generates a 1024-bit private encryption key using the RSA algorithm, named after its three inventors Ron Rivest, Adi Shamir, and Leonard Adleman. The encryption key is then encrypted with the DES3 algoritm, using the password contained in the PASS environment variable. Any program that wants to use this password-protected encryption key must be fed the password in some way.

$ openssl rsa -passin  env:PASS
              -in      rsa-private-key-with-password.key
              -out     rsa-private-key-without-password.key

This invocation of the rsa subcommand reads the password-protected encryption key and writes it to another file, without password-protection. We now have two incarnations of exactly the same encryption key. It does not matter which one we use. Password protection is only about keeping the key safe, not about the key itself.

$ openssl req -new
              -subj     "/CN=$DOMAIN"
              -key      rsa-private-key-without-password.key
              -out      certificate-signing-request.csr

Using an unprotected private key
PDF Image LaTeX source

This invocation of the req subcommand generates a “Certificate Signing Request”, which will be fed to the actual signing. The subject (-subj) is the information that goes into the certificate. Here, only the “Common Name” (CN) is specified (from the environment variable DOMAIN). For a website certificate, the Common Name must be equal to the site name. For my domain,, the actual subject is “/”. A more realistic subject would include e.g. location and contact information.

The Certificate Signing Request file is never encrypted.

openssl x509 -req
             -days    36500
             -in      certificate-signing-request.csr
             -out     certificate.cert
             -signkey rsa-private-key-without-password.key

Time to do the deed. This invocation of the x509 subcommand processes the Certificate Signing Request, signs it with the private key and sets a time limit of (nearly) 100 years on the resulting certificates validity.

The certificate file is never encrypted.

To actually use this certificate, we must copy it, and either the password-protected version or unprotected version of the private key, to a location where our web server can find them, and then configure the web server to use them. How to do this is outside the scope of this article.

Either of the two versions of the private key can be used. If the password-protected version is used, then the password has to be provided every time the web server starts. If the unprotected version is used, then great care must be taken with file permission.

The disadvantage with a certificate generated this way is that web browsers will complain loudly about this possibly unsafe certificate. We can improve on this by becoming our own Certificate Authority. This involves generating a special certificate and giving users the option of importing that certificate into the list of trusted Certificate Authorities.

That is the subject of the second and final article in his series.

Finally, we can create human-readable versions of the files:

openssl pkey -text
             -in rsa-private-key-without-password.key
              >  rsa-private-key-without-password.txt

openssl pkey -text
             -passin env:PASS
             -in rsa-private-key-with-password.key
              >  rsa-private-key-with-password.txt

openssl req  -text
             -in certificate-signing-request.csr
              >  certificate-signing-request.txt

openssl x509 -text
             -in certificate.cert
              >  certificate.txt

These files are just for human consumption; they are never used as input.

You can reach me by email at “lars dash 7 dot sdu dot se” or by telephone +46 705 189090

View source for the content of this page.