Openssl ca -config openssl.cnf -name CAroot -extensions v3ca -out signing-ca-1.crt -infiles signing-ca-1.csr Preparing a directory structure for the signing CA Now, we can create a directory structure for the signing key, using the same perl script we used to create the root CA directory structure. Use the root private key to sign the root certificate. (change DOMAINNAME to match what you used in the opensslroot.cnf): # openssl req -config opensslroot.cnf -new -x509 -sha512 -extensions v3ca -key /root/ca/private/ca.DOMAINNAME.key.pem -out /root/ca/certs/ca.DOMAINNAME.crt.pem -days 3650 -setserial 0.
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:
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:
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
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:
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
for instance C64 emulator retroarch.
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.
Openssl V3_ca 1
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:
We specified a Subordinate CA certificate insread a Root CA certificate with these options -CA .subcasubca.crt -CAkey .subcasubca.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:
- a Root CA certificate
- a Subordinate CA certificate
- 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.
Subject Alternative Names are a X509 Version 3 (RFC 2459) extension to allow an SSL certificate to specify multiple names that the certificate should match. SubjectAltName can contain email addresses, IP addresses, regular DNS host names, etc. There’s a clean enough list of browser compatibility here.
Changing /etc/ssl/openssl.cnf isn’t too hard. Although most the documentation is hard to grasp, especially if you’re only trying to make requests. From this, I developed these changes to a standard config provided by debian/ubuntu. Edit openssl.cnf and uncomment “x509_extensions = v3_ca” in the [ req ] section.
Annoyingly, nobody appears to have figured out how to get openssl to ask you for this value.
Openssl Extensions V3_ca
I thought I was clever putting ‘subjectAltName=email:move’ in the v3_req section, which would put the email address you type in the subjectAltName field. I’d put in “email@example.com, DNS:www1.example.org, DNS:www2.example.org” in the email field when ‘openssl req’ asked for it. Visually it worked, but the browsers didn’t like it. This appears to be functionality to deal with part 188.8.131.52 of the RFC, moving email address into subjectAltName.
I thought about writing a script that would copy openssl.cnf, ask me for the value of SubjectAltName, run sed against it, then start openssl. It would appear seamless, but of course be a hack.
A better answer lies here, you can configure openssl to use environment variables. At the top of openssl.cnf under where it set’s HOME=”…” I added
And in [ v3_req ] I added:
So if you run openssl like this:
It will fill in subjectAltName with the contents of the SAN variable, otherwise will fill it with the contents specified at the top of the file. There’s no way to use conditionals (I assume).If you just leave it blank, or leave it out altogether, you get these errors: