Setting up a own CA for the enterprise

Inside an enterprise there are a lot of machines communicating with each other. It is necessary to keep these communications secure and private. This can be achieved through encryption.

In the enterprise SOA the most important protocol is HTTP. The encrypted version is HTTPS and needs at least one certificate. The certificate is the host certificate of the server and must be trusted on client side. For details have a look at this post.

The needed certificate can be bought with a yearly fee of some euros from an official certificate authority. An other possibility is to just use the certificates generated by the systems themselves (‘snakeoil’ certificate).

But if the enterprise needs many certificates a better solution is to set up a own certificate authority for the enterprise.

Don’t underestimate the effort for having your own CA. The effort is not in first place for setting up the CA or generating the certificates. Much more time is needed for the education of the employees handling the CA, the organizational processes and the documentation of issued certificates, keys and their lifetime. At official certificate authorities there are hundreds of folders describing how the employees have to act in different situations, who has the permissions to do what, who can substitute key persons and so on. Even if you don’t need such complex processes there should be some definitions about the confidentiality of the CA and the generated certificates and substations for the employee handling the CA.

I will describe how to do the serveral actions with openssl on a linux machine. Of course a current version of openssl should be used.

openssl.cnf

The first step for setting up the CA is to create or modify the file openssl.cnf. When I started to set up the CA I was surprised how difficult to understand and bad the documentation of this file was. In fact I was missing an example of the file with current settings and without everything else which is not really needed. The extension system of the openssl.cnf file makes it quite difficult to understand. If some reader has suggestions to improve it, I would be very appreciated.

In the first section CA_default the location of different files is described. The line ‘default_ca = CA_default’ is an inclusion of the CA_default extension.

If unique_subject  = no is commented out, it is necessary to revoke every old certificate until a new one with the same subject can be generated.

The value default_days = 365 issues by default certificates with the validity of a year.

The extension policy_match defines how certificate requests to be signed by this CA must be. It is activated by the line ‘policy = policy_match’.

Next one is the extension req. It will be activated if we are creating a certificate signing request. We set the default rsa key length to 2048 bit and the default algorithm to SHA-2.

With req_distinguished_name we set up the defaults for the CN and the other attributes of the certificate.

After that I decided to create three different extensions for the three different use cases: root_ca_extensions, client_ca_extensions and server_ca_extensions. The used extension is selected during the signing of the csr.

In my first tries the client_ca_extensions and server_ca_extensions had different extendedKeyUsage settings: 1.3.6.1.5.5.7.3.2 for the client and 1.3.6.1.5.5.7.3.1 for the server. In my opinion this should be enough, but I later found some unexpected behaviors on one system perhaps triggered by this so I didn’t do further research and added both key usages to both certificates.

For the field keyUsage I found a good describing comment on stackexchange. To sum up: Needed usages depends on the cipher suite, that’s why it is recommend to add all 4.

Creating the CA key and self signing the CA certificate

First we generate the private key of the root CA and store it encrypted in a file:

ROOT_CA_KEY is the encrypted private key file of the root certificate of the CA.

The second step is to create the certificate of the root CA:

ROOT_CA_PWD is the password for the private key of the root certificate.

ROOT_CA_CRT is the root certificate of the CA.

Now our CA is ready to create certificates with associated private keys and signing certificate signing requests.

Creating a client certificate with the associated private key

I have implemented for all three use cases the same two steps, even if they could be combined or are not necessary in some cases:

• Create a certificate signing request and a private key (file extensions csr and key)
• Signing the certificate signing request and generating the certificate (file extension crt)

In many examples the private key file and the certificate file use the extension pem. I prefer the extensions key and crt to make it more clear, what is inside the file.

In this use case we create the csr and the key with the command:

KEY is the filename with path of the generated private key file

CSR is the filename with path of the generated certificate signing request file

CERT_CN is the identifier of the user/system using this client certificate. This could be e.g. Mister Someone or CRM.

CERT_EMAIL is the mail address of the user or using system.

The second step is to sign the csr and create the certificate:

CRT is the filename with path of the generated certificate file

We use the client_ca_extensions for creating this certificate.

It is highly recommend not just to execute the two command on the shell. Instead the commands should be wrapped into shell script having only one or two parameters and defining the folders, filenames, pattern for naming and so on. Otherwise, especially if different employees are issuing certificates, the overview about the certificates will be lost very soon.

Creating a host certificate with the associated private key

In this use case we create the csr and the key with the command:

KEY is the filename with path of the generated private key file

CSR is the filename with path of the generated certificate signing request file

CERT_CN is the full qualified hostname of the machine.

The second step is to sign the csr and create the certificate:

CRT is the filename with path of the generated certificate file

We use the server_ca_extensions for creating this certificate.

Signing a host certificate request

In this use case the csr is created on an other system and provided for signing. Also the private key file associated to the certificate signing request stays on the other system and is not needed for the signing process. Only the second step is to sign the csr and create the certificate is excuted:

CSR is the filename with path of the certificate signing request file provided

CRT is the filename with path of the generated certificate file

We use the server_ca_extensions for creating this certificate.

Bernhard Mähr @ OPITZ-CONSULTING published at http://thecattlecrew.wordpress.com/