Setting up your own certificate authority with gnoMint

gnoMint is a desktop application that lets you easily manage your own certificate authority (CA). Many secure communications technologies use digital certificates to ensure that the party or service they are connecting with is not an impostor. For many people, the main exposure to digital certificates comes when they visit an HTTPS Web site and see a certificate to validate that they have contacted the right Web server.

Such a certificate can be trusted because it has been signed by a trusted CA. The process to get a certificate signed by a CA varies, but generally you generate a Certificate Signing Request (CSR) and send it to the CA, which then verifies that the signing request has not been tampered with and that you are the sender and are who you claim to be. The level of verification that the CA performs to determine that the sender is the correct person varies. Once the CA is satisfied, it will sign the CSR, creating a valid certificate. Users who go to a Web site can then be served this certificate and verify that they have contacted the right Web site by checking the CA’s signature on the certificate. Web browsers have a collection of CAs that they trust (and the public keys of those sites, for signature verification) and can assume that any certificates signed by those CAs are valid.

Running your own CA has some downsides depending on how you plan to use the certificates you generate. The main downsides come if you are planning to use your own certificates on public servers. In that case, clients contacting your servers will have no way to know whether they can trust the certificates your sites present, because the list of known CAs shipped with Web browsers does not contain any information about your CA.

If you plan to use certificates on public servers, there are services around like StartSSL that provide free certificate signing, or you can purchase a signed certificate for as low as $20 per year.

If, on the other hand, you are planning to use your certificates to allow a select group of users to contact private servers, then using your own CA can be quite convenient. Having your own CA means you can generate 20 signed certificates in a few hours without having to deal with any external CA. You can also nominate that the certificates you generate will remain valid for longer periods of time — decades, even. Another upshot of the agility of generating your own signed certificates is that you can generate certificates for use by clients as well as servers. For webmail interfaces, for instance, knowing that the client is legitimate might be as important as knowing that the server is legitimate. Client certificates also provide a higher level of security for client-server applications, as an attacker must compromise a client certificate in order to obtain access to the server.

Go go gnoMint

gnoMint is not packaged for openSUSE, Fedora, or Ubuntu. I’ll build version 0.5.3 of gnoMint from source using on a 64-bit Fedora 9 machine as shown below. gnoMint uses the GNU Transport Layer Security Library for its cryptography and SQLite3 to store all of the information required for a CA in a single file.

$ tar xzvf /.../gnomint-0.5.3.tar.gz
$ cd ./gnomint*/
$ ./configure 
$ make
$ sudo make install

In the gnoMint screenshot below, the main CA is example.com, and I have generated and signed a certificate request for la.com and subsequently revoked that certificate. The foo certificate has been signed, and the aruba.example.com certificate request has been generated but is not yet signed for use.

A recent high profile bug in Debian shows that having good random data is an absolute requirement for strong cryptography. For example, when you are generating keys you want the values used as parts of these new keys to be completely non-predictable so that anyone trying to break your encryption has to try a huge number of possible values to guess what your key might be. If you are experimenting with gnoMint, you might run out of strong random data on your machine before you start generating certificates that you are actually going to use. Network traffic and mouse and keyboard activity will gradually restore your random data. If you do not have enough random data, gnoMint will wait until it can get enough, which might take a while.

One area where a lot of random data is required is the first operation you are likely to perform, adding a self-signed certificate (which you will then use to sign other certificates) to your certificate database. While you are playing around you might like to use lower-quality random data by running the commands below. This makes gnoMint much more responsive but generates weak keys; because the random data used is less random the keys might be easier for an attacker to guess. Make sure that you do not use any keys generated while the below changes are still in effect. The best thing to do is to play with gnoMint, then wipe the whole CA, revert the below changes, and start using gnoMint in earnest to generate a new CA and set of keys that you wish to use.

# mv /dev/random /dev/random-real
# ln -s /dev/urandom  /dev/random

Use of gnoMint to generate and use a CA is straightforward if you are already aware of the terminology used for certificates, signing requests, chains of trust, and have an idea of how to manage a CA. The first thing to do is to select “New certificate database” from the Certificates menu. Next, generate self-signed certificates for the CA itself by choosing Certificates -> Add -> Add self-signed CA. You’ll have the opportunity to enter the country, state, and city where your new CA is located, along with three more parameters might make those unfamiliar with certificates scratch their heads: the organization, organization unit, and the Root CA common name. For your own CA you are free to use whatever you would like for the organization and organization unit. The common name (CN) of a certificate should match the DNS host name of the host that is being authenticated. For your own CA, it doesn’t matter too much what the CN is, but if you are generating a certificate for the server side of an HTTPS connection, you should set the CN to the host name of the server.

Once you have inserted the identity information for your new CA, the next page of the dialog allows you to choose RSA or DSA cryptography, the bit length of the CA’s key, and how long until it expires in months. The maximum time until the CA certificate expires is 50 years. The key bit length can be any multiple of 1,024 bits up to 5,120 bits.

Once you have a CA, choose Certificates -> Add -> Add Certificate Request. You will get a dialog asking for the same identity information you entered for your CA certificate, followed by key size selection. The certificate expiration time is selected by the CA, and not included in the CSR.

At this stage the GUI will show an outstanding CSR, like aruba.example.com in the above screenshot. To make this CSR into a valid certificate, just right-click it and select Sign. You will be presented with the details from the certificate, asked which CA certificate you wish to use to sign with, and then asked for how long the certificate should be valid and what you endorse it to be used for. The below screenshot shows this final step. Strangely, the window title is “New CA” although we are signing a CSR.

Now the certificate will be displayed as a child of your CA certificate in gnoMint’s tree view. Right-clicking the signed certificate and selecting Export from the context menu will show you the export dialog from the screenshot below. If you are planning to use your self-signed certificate with Apache, you should export the key using both the first and third options — public and private parts into PEM format.

The /etc/httpd/conf.d/ssl.conf file should list the path for the SSLCertificateFile and SSLCertificateKeyFile files, which contain the public and private keys for the Apache Web server respectively. Copy the public key in PEM format (the first option in the export dialog) to the path shown for the SSLCertificateFile directive, which was /etc/pki/tls/certs/localhost.crt for my machine. Copy the private key in PEM format (the third option in the export dialog) to the path listed for the SSLCertificateKeyFile directive, which was /etc/pki/tls/private/localhost.key for my machine.

Once your self-signed certificate is in place on your Web server, browsing your Web site in Firefox will generate the error sec_error_unknown_issuer because you have used your own CA and Firefox does not know anything about it. To solve this problem you should right-click the CA key in gnoMint and export only the public part of the key in PEM format. Then, under Edit -> Preferences -> Advanced -> Encryption, click the View Certificates button. In the dialog window that appears, choose the Authorities tab and click the “Import…” button. Open the public key in PEM format that you exported from gnoMint, select the “Trust this CA to identify web sites” checkbox, and click OK to all the preferences dialogs you had open. Now you should be able to browse the Web server that uses your own CA’s certificates and Firefox should not complain.

The main issue I had with gnoMint was that when the machine runs out of proper random data, the gnoMint interface can just sit there, not frozen, but also with no indication of how close it is to generating the key or performing the operation that needs more random information. That being said, gnoMint makes running a small CA much simpler than using the OpenSSL command-line utilities or other lower-level methods. The export dialog offers valuable insight into which format you should choose to make the certificate or key in for the purpose you have in mind.

If you know roughly how a CA works at a conceptual level, you should be able to generate and use certificates fairly quickly with gnoMint.