You are here

gnoMint tutorial

Translations: Ukranian

Let's imagine you are the system administrator of a firm. You have hired two different servers for backing up all your data redundantly, in two different and distant datacenters. Your boss ask you to setup a VPN, so the access to the data in the servers can be done easily. That VPN is going to be used too for connecting the four firm offices that are spread all over the country.

We are going to create the VPN using OpenVPN software, a reliable system that uses SSL for tunnelling the comunications. We suppose that all your servers are Linux. And you are going to use X.509 certificates for authenticating remote peers, so the VPN can grow easily without too much trouble. In this tutorial we will cover how to manage the needed Public Key Infraestructure using gnoMint.

Setting up your CA

First of all, you must setup your Certification Authority. It's true that OpenVPN carries its own scripts (easy-rsa) for setting up a little CA infraestructure, based in openssl, and perhaps they are enough for what you need. But gnoMint lets you to manage the CA in a more confortable way, always seeing the current status of your installation. And with gnoMint you can look further than a simply VPN-oriented CA.

By the way: if you already have a OpenSSL CA (as the ones made through openssl's CA script, tinyCA, OpenVPN's easy-rsa...), you must know that gnoMint, since 0.6.0 version, can import them into a gnoMint database.

Before launching any application, let's think a little bit about the CA we are going to create. In this example we want to create a single Root Certification Authority for your firm, so we control all the issued certificates from only one database. This Root Certification Authority will issue CA-capable certificates, that will be specialized (as it is recommended that a given CA issues certificates with the same properties).

  • We will create a second-level CA for VPN system identification (the example firm will use OpenVPN).
  • Another secondary CA for identifying employees in the firm (perhaps for using for transmitting top-secret information through mail).
  • And another for software signing (as the Software Development Department wants to sign all the security patches so the produced software can upgrade only with chryptographically signed patches).

Generating the Root CA certificate

So you install the last version of gnoMint (for following this tutorial, it must be, at least, 0.5.3 version). You can download it from SourceForge, Launchpad, or with a bit of luck, from your favourite distribution repository. After installing it, you can start it using:

$ gnomint &

The main window of gnoMint will appear, with the default database (~/.gnomint/default.gnomint) opened:

Now, we will create the private key and self-signed certificate for the CA. For doing that, in the Certificates menu, choose "Add/Add self-signed CA". A window will open asking us data for the new CA certificate.

Window for entering new CA Properties 

After completing the initial data for the CA, press Next button. In this step, we must choose the kind of ciphering we are going to use while creating this new CA. We choose RSA (though you can choose DSA if you prefer it). As we want it to last for a long time (20 years), we are going to choose a long private key, with a bit length of 4096, or even better, 5120. The months before root certificate expiration will be 20 years: 240 months.

After pressing OK, the CA Root private/public key and certificate generation will be in progress. After a while, you will get the next screen:

 

Now, we have created our Root CA certificate and private key. The little seal icon in the certificate says that the certificate is a Certification Authority (that is, can be used for generating other certificates).

The keys icon says that the certificate corresponding private key resides in the database. This can be a security problem. Anyone with access to a copy of the gnoMint database file will be able to generate certificates, and introduce his own machines to the VPN.

Protecting gnoMint database

For avoiding this situation, gnoMint has two different, not exclusionary, alternatives:

  • You can crypt all the private (secret) keys in the database with a passphrase, so that only authorized people can use the private keys in the database.
    All the private keys in the database will be ciphered using a AES256 algorithm, in CTR mode. NSA considers AES, with 256 key length, as enough secure for archiving TOP SECRET documentation.
  • Other alternative is keeping the Root CA private key in a passphrase-protected external file. For increasing security, this file can reside in an external removable device, such as a little USB drive that is usually kept safe and is used only when you need to sign something with the CA Root certificate.

Independently of if you extract your private keys to extern files or devices, it's always recommended to passphrase-protect gnoMint database, so there is not clear private data in it.

In this tutorial, we will choose the first option alone, as it is the simpliest. Click in "Change Database Password", in Certificates menu.

After selecting to do protect CA database private keys with passwords, and entering twice the new passphrase, the database will be secured.

Establishing Root-CA policies

OK. We have a Root-CA certificate. Now we are going to establish its policies: we double-click it, or after selecting it, choose Properties in Edit menu. The certificate properties window will appear. In its third tab we can modify the CA policies.

 

The CA Root will generate secondary CA certificates. So we need to select, in the "Uses of new generated certificates" section, "Certification Authority" and "CRL generation".

Also, we want to force the secondary CA certificates to belong to the firm. So we force that the country and organization fields of the secondary CA certificates to have the same value as the ones in the Root CA. The other fields will have, as a default value, the same as the one in Root CA, but can be modified afterwards.

Also, we establish that these secondary CA certificates will expire 5 years (60 months) after their creation, and will that the estimated time between CRL issuing will be 7 days (168 hours).

Creating certificate signing requests for secondary CAs

Everything is ready for creating the secondary CAs. For doing that, the first step is creating their CSRs (certificate signing requests). These CSRs will be signed by the Root CA, conforming the secondary CA certificates.

In the Certificate menu, we choose "Add/Add Certificate Request". In the new window, we select to inherit fields from Root CA, and press Next button.

 

After that, we must enter the data for the new Certificate Request. First, we will going to create the CSR for the CA that will issue certificates for systems authorized to enter in the VPN.

After pressing Next button, we choose the ciphering properties for the CSR (that is, for the new certificate). We keep on using RSA, but as this certificate will expire before, we choose only 2048 bits for private key length.

After this, if the database is password protected, gnoMint will ask us the database password, as it is needed to cipher the private key in the CSR before saving it in the database.

Perhaps, you have seen the window saying that the CSR was correctly created, but you can't see it anywhere. In that case, check in the View menu if Certificate Signing Requests is checked. If not, check it, and... Voilà! There it is. 

OK. We have the CSR for the first secondary CA (the VPN related one) in the database. Now we repeat the previous steps for creating another two CSRs, one for Employees CA, and the other one for Software Signing CA. Now all the CSRs for secondary CAs are created.

Signing CSRs to create Certificates

Now, we are going to sign all the CSRs with the Root CA certificate, so they become our secondary CA certificates.

So, select one of the certificates, and click in the "Certificates/Sign" menu entry, or click the CSR with the secondary mouse button and then select "Sign" in the contextual menu. The following window will appear. Here you must check that this is the correct CSR.

After pressing Next, you must select the CA that is going to sign the current CSR. In our case, select the only CA.

After this you will be able to select the certificate properties. The recommended option is configuring all certificate properties through CA policies, but with this window you can custom the properties of any particular certificate (only before creating it!!).

It must be noted that you cannot change the properties of a certificate in a way not allowed by the CA policies. So, for example, if the policy of the Root CA only allows certificates with Certification Authority and CRL signing uses, you cannot activate Digital signature use in a new certificate signed by the Root CA. 

After pressing OK, the application will ask for the DB password, as it must access the Root CA private key. After entering it, the CSR will be signed, and then we will have our first secondary CA ready for action.

Now we repeat the last steps with the other two CSRs, and then we will have three secondary CAs, one for each desired use.

Defining secondary CA policies

Now we must define the policies for the secondary CAs.

Systems CA

First, the VPN systems CA. The certificates created with this CA should be used for digital signature, key encipherment, and key agreement. Its enabled purposes must be TLS web server, and TLS web client (as these bits can be read as "TLS server" and "TLS client", without the "web" part).

As an exception to the given rule, we will only want one certificate (the one that will be used in the VPN server system) with the "TLS web server" bit active. This can be achieved with a manual deactivation of the bit in each certificate creation, or deactivating the server bit after the creation of the certificate for the server system. We will use the latter option.

Employees CA

We want the employees CA to emit a certificate for each firm employee. They should be able to use these certificates for email authentication (signing and ciphering too), and for web authentication (so they could enter in the intranet of the firm automagically).

The certificates created with this CA should be used for digital signature, key encipherment, and key agreement. Its enabled purposes must be TLS web client and Email protection.

 

Software signing CA

Each one of the development groups will have their software signing certificate used for signing security patches and new versions. 

The certificates created with this CA should be used only for digital signature. Its only enabled purpose must be code signing.

OK. We are ready to start creating the final certificates. Let's go, then.

Creating system certificates

Once our CAs are set up, first we will create the certificates corresponding to systems in our VPN.

The VPN will be formed by a central server that will listen for incomming connections from machines deployed in delegations all over the country. So we are going to create a certificate for the VPN server (in Madrid, Spain), and then two client certificates (for Barcelona and Seville delegations). So we will create Certificate Signing Requests for the three VPN nodes.

A more secure approximation would tell you that Barcelona and Seville delegations should create their own CSR. With gnoMint this is possible: they could create a CSR using gnoMint, export it to a PEM file (or create the CSR with any other program) and then send it to you by e-mail or any other methods. As a CSR doesn't contain any private information, it can be sent through insecure channels.

Let's suppose that this-more-secure approximation is not possible, because we are the only technical-enabled employees in the firm. So the three CSRs will be created by us.

Click on Certificates/Add/Add Certificate Request. The next window will appear. We choose to inherit properties from the Systems CA, as it is the one that we designed for issuing certificates for the VPN nodes.

CA selection for the new CSRs

After pressing Next button, we must complete the CSR subject information. Although it is not mandatory, we should fill all the fields with correct information.

New CSR subject properties

Once the subject info is correct, we press Next and select properties for the public/private key pair. A key length of 2048 should be OK, at the moment (2008). Remember that, according to the progression in CPU speeds, current safe key-lengths could get unsafe in a few years time.

CSR Key pair properties

After we press OK, the CSR and its corresponding private key will be created. Now we must repeat this process twice again, for creating CSRs for Barcelona and Seville delegations, so we end up with this screen.

After creating CSR certificates for VPN nodes

Now, we will sign these CSR for obtain the VPN-node certificates.

(To be continued...)