How to make Subordinate CA using OpenSSL

Although all certificates can be issued by the single Root CA authority, you will sometimes have a need to make a Subordinate (or Intermediate) CA authority. In most cases, this is related to the increased security needs or higher flexibility.

When you generate a Subordinate CA certificate, you will use it later to issue all other certificates. In case that such Subordinate CA certificate is compromised for any reason, only that branch in your PKI will be compromised. Your Root CA certificate remains unaffected and all you need to do is to renew only one subset of certificates.

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.

Before we begin, please be sure that you have the section named [ v3_ca ] in your openssl.conf file. It’s usually there and should look like this:

# Extensions for a typical CA

# PKIX recommendation.

subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer

# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.

basicConstraints = CA:true

# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
keyUsage = cRLSign, keyCertSign

# Some might want this also
nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation
subjectAltName = email:copy

# Copy issuer details
issuerAltName = issuer:copy

# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF

These settings are good enough for the most scenarios. Nonetheless, we can specify other options, but that discussion is beyond this post.

I will use this batch file, as I already made it for me. Of course, I will explain in detail all relevant commands.

I’m using subfolders inside my OpenSSL folder and I will place my SubCA certificate in the folder named subca. I will again use my virtual CA authority named SuperCert and I will made one intermediate certificate for that body. The certificate name will be subca.

 

Making a private key

This first step is always the same – generating a private key. This is the command:

openssl genrsa -out .\subca\%1.key 4096

This process will take a while, depending on the key size and computer speed.

I generated a 4096 bits long private key. Although you can use only 1024 bits for a test certificate, my recommendation is to always use at least 2048 bits long keys.

I didn’t signed it because I will use it only in my lab. As always, bear in mind that you should sign with password any CA private key.

 

Generating a certificate request

This step is also the same and we’re using it with any certificate. The command is

openssl req -new -key .\subca\%1.key -out .\subca\%1.csr

We will answer on a few question, as always. This is also CA certificate and I will enter SubCA as its Common Name.

As I mentioned in this post, a CA server itself is virtual. This is the key concept!

You don’t need any machine that will be visible in the network. In addition, this certificate will never be used for any other purpose except to sign other certificates. Therefore, this common name can be anything you like.

Yes, I hear your question – if this server is virtual, how I can sign my device certificate. The answer is simple. You can do that manually, running OpenSSL on any machine. A virtual machine is a good choice. Ideally, that machine will be disconnected from the network. You will use a certificate request file and your Root CA files to issue a new certificate.

Alternate way is to use any server with the Web interface to allow end-users to perform this task by themselves. However, the network name of that server isn’t related to the name of the CA authority. You can even issue a certificate for that Web server signed by the same CA authority.

 

Generating a certificate

You are already familiar even with the last step. We need to generate a certificate based on a supplied request file.

The command is:

openssl x509 -req -days 365 -in .\subca\%1.csr -CA .\cacert\ca.crt -CAkey .\cacert\ca.key -CAcreateserial -out .\subca\%1.crt -extfile openssl.cfg -extensions v3_ca

This process is quick and in split second, we will have our SubCA certificate.

Before we proceed further, I want to highlight important options in this command. The option -days 365 will generate a certificate with the validity period of one year. That is fine for my test certificate. I will probably dump it much earlier.

In case that you want to generate the real one, you should consider to specify a significantly longer period. Nonetheless, you can generate it only for one year and then simply renew it, exactly as I described in this post. From the security standpoint, this has a sense.

These two options -extfile openssl.cfg -extensions v3_ca are also very important. The first option named extfile indicates where are located all necessary configuration parameters. Those parameters are always specified in pairs like

parameter = value

for instance

basicConstraints = CA:true

Any line that begins with # sign will be ignored and treated like a comment.

The second option named extensions will specify the name of the configuration section. This name is mandatory even if we have only one configuration section in a file. The openssl.conf file already contains all commonly needed sections. You may edit this file or even define your own sections.

In this case, we need to specify this section related to CA servers. This section contains all settings required by any CA server. Otherwise, OpenSSL will use regular user section and this crutial CA flag will be set to FALSE.

 

How you can use this Subordinate CA certificate?

We just generated another CA certificate. It can be used to issue (sign) other certificates. When we open this certificate in Windows, we will see the following:

This certificate is signed by our RootCA certificate. I also encircled that message on this dialog. That is also the clarification of my previous discussion – we need to import that RootCA certificate in a device’s certificate store to enable a chain of trust.

If we have a Root CA certificate imported on our device, we can check all other certificates signed by it. Otherwise, we will not trust them. There’s no direct contact with any CA authority, only CA certificates already loaded on that device.

We can now use our Subordinate CA certificate to sign either a server or a mobile device certificate. That new command need to be slightly changed:

openssl x509 -req -days 60 -in .\requests\%1.csr -CA .\subca\subca.crt -CAkey .\subca\subca.key -set_serial %serial% -out .\certs\%1.crt -extfile openssl.cfg

We specified a Subordinate CA certificate insread a Root CA certificate with these options -CA .\subca\subca.crt -CAkey .\subca\subca.key.

Bear in mind, in cases when we’re using also a Subordinate CA certificate, we must import it on our devices, too. A Root CA certificate signs a Subordinate CA certificate and a Subordinate CA certificate signs a device certificate. That’s the chain of trust.

In such case, we will import certificates in the following order:

1. a Root CA certificate
2. a Subordinate CA certificate
3. any depending device certificates

The story about computer certificate is huge and I will probably need a thick book to say it all. I focused here only a few most common scenarios. I will use those procedures to make certificates for all routers, servers and client devices that I plan to use in my upcoming articles related to the L2TP/IPsec RSA tunnels, IPsec with certificates tunnels, e-mail services, etc.

Stay tuned.