Creating digital certificates with our root certificate

From SaruWiki
Revision as of 01:20, 28 October 2008 by Saruman! (talk | contribs) (Page started)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Preparing for certificate creation

When we're going to create certificates, we're going to use the openssl command twice:

  • once to create a "certificate signing request", in which we define all information to be included in the certificate, and actually generate the public and private key parts of the key pair, and
  • once to instruct the OpenSSL package to sign the certificate with our CA root certificate.

The first step thus creates the actual keypair, and the second step signs the public key.

However, we're going to need to input a lot of parameters on the openssl command line. We can make things a bit easier for us by specifying these in the openssl.cnf file, just as we have added some values when creating the CA itself. To be precise, we're going to add X.509 V3 extensions

By default OpenSSL generates V1 certificates, but if we're not extremely worried about offending certain ancient web browsers, we can add V3 extensions, and even make openssl do that by default. To do this, we find in openssl.cnf the following line in the section [ req ], which is likely present but commented out:

req_extensions = v3_req # The extensions to add to a certificate request

Simply remove the # sign in front of it, so that it appears as given above. This by default enables V3 extensions.

Furthermore, check the section [ v3_req ]. It should look like this:

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectKeyIdentifier = hash

What is added is the last line, with subjectKeyIdentifier; this line specifies how to identify the public key being certified, so that distinct keys used by the same subject can be differentiated (e.g. as key updating occurs, for example). Four values are possible, but the IETF Public Key Infrastructure (PKIX) working group recommends the setting subjectKeyIdentifier=hash

Creating an SSL certificate

Now we can create an SSL certificate for a web server. For the Common Name of the certificate, we need the exact name of the web server that'll offer the SSL connections. However, some servers run different websites as Virtual Hosts, so they could be running, for example, www.saruman.biz, as well as shop.saruman.biz. That might present a problem, because if the certificate is issued for www.saruman.biz, then each visitor of shop.saruman.biz will get a warning along the lines of "Warning: The website you're trying to visit is shop.saruman.biz, but the certificate offered is for www.saruman.biz". To prevent that, we could use the wildcard character in the name of the certificate, so as to generate a certificate for *.saruman.biz.

So with that out of the way, we now perform the first step in our certificate generation: we create a signing request with all the information that we want in our SSL certificate. We run the magic incantation

openssl req -new -nodes -keyout saruman.biz.mykey.pem -out saruman.biz.req.pem

This generates a new private key (named saruman.biz.mykey.pem), and a new, non-encrypted (because of -nodes), key signing request named saruman.biz.req.pem. We can leave out terms like -newkey rsa:2048 and -days 370 since we've put that in the configuration file. And naturally you're free to choose your own names for the keys.