Simple CA infrastructure with OpenSSL

Companies and users need more and more certificates in their everyday business. We can use certificates to protect any type of communication, from exchanging e-mails to e-commerce sites.

Depending on our needs and the work that we do, we can use either privately generated certificates or those signed by third party body. Most important difference is who generated the primary certificate and whether both sides trust the issuer.

When we need a simple certificates infrastructure only for our company or private project, we can make it easily and free of charge. We will make all necessary steps to generate certificates and distribute them to users. We can easily distribute our certificates within the corporate network through the Windows Group Policies.

Today, many employees are working from home or while on the road. We need to allow them access to our corporate network. That access can be limited only on the few services or unrestricted to the whole network. Of course, the most important part here is the VPN tunnel. We must protect the access mechanism and all data that are exchanged through that VPN tunnel.

Some VPN tunnels, which are widely used in today corporate world and depend on certificates, are Microsoft SSTP and OpenVPN. Although the Microsoft developed the SSTP protocol specification, it is also natively used on Mikrotik devices.

The OpenVPN protocol can be used on virtually any platform. It requires an installation of the separate client packet. There are several implementations on the Internet. However, not all of them are equally good to be used. Of course, Mikrotik devices natively support this protocol.

A word of caution. Check your local laws and regulations relating to security, cryptography, etc. In some countries, using the OpenSSL package can be against the law. In such case, you must stop reading this article and you should not follow any instruction mentioned here. It is solely within your responsibility.

 

What we need for our recipe

We can build our simple CA infrastructure using OpenSSL package. This packet is the cross-platform open source product. We can find it in many Linux distributions. For Windows platform, we can find pre-built packages either here or here. Do not miss the manual section on the site.

We should always check the latest version of the OpenSSL package and update it if needed. Moreover, we should always check if the framework offers a new options inside the old commands. During the time, encryption standards evolve and replace each other. The same applies to the best practices relating to security.

Although I worked on a Windows platform, all commands mentioned here are same on all platforms. Furthermore, it does not matter whether you use the 32- or 64-bit version of the package. The certificate will be the same.

I downloaded the light 32-bit version from the first site. Always check the latest version in the download section. A download will be quick, as this is a small package with a size of only 2 MB. As this is a version with the installer, run the downloaded file and install the OpenSSL package. After installation, you can use it as a portable version.

 

Making simple CA infrastructure

We want to make a very simple CA infrastructure. That means that we will not need to make a many changes inside the OpenSSL package, if any at all.

Go to the OpenSSL directory (or folder, if you like that name more). We will work on the command line. There are some graphical environments for the OpenSSL. However, work on the command prompt is very simple once you learn a few commands and options.

The first step is to create (generate) the CA certificate and related key. This is the master certificate for the whole infrastructure. We will sign all other certificates with this one.

Bear in mind that if this certificate (and especially its private key) is compromised then the whole CA infrastructure is compromised and useless. In that case, you will need to build it again from the scratch. Therefore, you must protect the private key and you should never give it to anyone.

We will first generate the private key. This can be done with the command:

openssl genrsa -des3 -out ca.key 4096

This command will generate a new key named ca.key with the length of 4096 bits and using the 3DES encryption standard. However, today is preferred to use AES encryption. Therefore, we should use at least an option –aes128 instead -des3.

In case that we do not want to password-protect the private key, we can add an option –nodes. However, this option should not be used on the CA private key. Bear this in mind.

If you open this file, you will see a bunch of characters inside.

The password we used to create this certificate (I used Test123 in this example; however you should use the passphrase in the real case) will be needed for further usage. Therefore, remember it or write it down in the secure place.

We can see the contents of the certificate’s key with an another command. Execute this command on the command prompt:

openssl rsa -in ca.key -text –noout

Instead of the ca.key you should type a name of the file you want to check.

As you can see on the screenshot, when we executed this command, we were asked to enter the password for this key.

Now we can generate the certificate. We will use following command:

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

This command will generate the CA certificate named ca.crt for 10 years (3650 days) with the private key ca.key. The default validity for new certificates is one year or 365 days. However, it is common practice to use long-term validity of the CA certificate and to generate device certificates with a validity of one year.

In case that the command return following output and just exit:

WARNING: can't open config file: /usr/local/ssl/openssl.cnf

Unable to load config info from /usr/local/ssl/openssl.cnf

you should either define the openssl_conf environment variable or add the option -config filename, where a filename is the name and location of the opsenssl.cfg file. We can add just .\openssl.cfg in most cases.

Our command now will be:

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -config .\openssl.cfg

The command will begin process and so we will have to answer a few questions.

Of course, the first question is about your password for the private key. Without this information, we cannot proceed further. Other questions are related to the country, company and server name.

The most important part for machine certificates is a common name. This must be either a full DNS name, also known as a FQDN (like router.contoso.com) or an IP address for that device (like 203.0.113.17). Bear in mind that wrong information provided here can prevent regular operations and, as consequence, we will have degraded or deferred service.

We can again check our certificate with the command:

openssl x509 -in ca.crt -text –noout

This command will output a detailed information about our certificate. We can check the validity period, issuer or device identification. We can also check if the certificate belongs to the CA server or not.

If we open this new CA certificate inside Windows, we can see all those details and one important warning.

This certificate is not considered trusted. We should add it inside the Trusted Root Certification Authorities store in Windows. Depending on the purpose of this CA certificate, we should consider this store for either user or computer.

 

Certifying device

Our shiny new CA certificate is useless if we did not sign at least one device. In our example, we will sign the certificate for our router named router.contoso.com, with the IP address 203.0.113.17.

Of course, this is the test router inside my virtual lab. Furthermore, the IP address 203.0.113.17 belongs to the TEST-NET-3 subnet 203.0.113.0/24 as described in the RFC 5735.

Commands are almost the same. The first step is to generate the private key. We can modify this command and add the option –nodes. This option will omit the password protection.

openssl genrsa -des3 -out server.key 4096

The second step is to generate a certificate request. We should provide so-called the request file (usually with the .req extension) to the CA body that will generate the certificate for us.

openssl req -new -key server.key -out server.csr

In this command, we will use the key generated in the first step to prepare our request file. Again, we should to answer a few questions and we will have our request file. The extension req is not mandatory. You can assign any extension to the request file. In my example it is the .csr.

Here is one trick. We can use the openssl req command to generate in the same time key and request. Then we will use slightly different command:

openssl req -newkey rsa:2048 -keyout server.key -out server.csr -config .\openssl.cfg

If we want a longer key then 2048 bits, we can use rsa:4096 in this command. My advice is to not use key shorter than 1024 bits. Moreover, the result is the same as when we use two commands.

Now we should use this new request file to make the certificate. The command is:

openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

We should provide the password for the CA key and command will do the rest.

We can check our device certificate and it should be dependent of our CA certificate. We will not see this dependence until we install the CA certificate in the Trusted Root Certificates store. However, we will always see this first page.

When we have installed the CA certificate, then we will see also this dependence:

It should say that the certificate is OK. Bear in mind that only the CA certificate needs to be imported in the store.

 

We have our simple CA infrastructure

We built the CA certificate and one server certificate. That is enough to start using this whole infrastructure. We should install both certificates on our device (in this case the Mikrotik router) and share the CA certificate with the users. Again, the CA private key should never be given to anyone.

When entering the common name of the device in the certificate request, the most important thing is to provide either the IP address or FQDN. If your router has no DNS name, then put the IP address. If you make a mistake with this information, Windows stations will not be able to establish SSTP VPN tunnel and we will have the errors relating to the server’s name (like domain mismatch, etc.).

To any Windows 7 and later host be able to access the SSTP server, you will need to have installed ca.crt certificate as a Trusted Root Certificate in the computer store. Two Mikrotiks will establish SSTP communication on their own even if we do not provide certificates. However, for greater security we can provide our certificates and ask for the certification check.

Advertisement