Running a Mini-CA

In Chapter 8, X.509 Certificates and PKI, we learned about Public Key Infrastructure (PKI) based on X.509 certificates. In this chapter, we will learn how to use the openssl ca subcommand to run a mini-Certificate Authority (CA) that can issue certificates for internal usage in an organization. A mini-CA can be useful in organizations for establishing internal PKI, gaining control of internally used certificates, and saving costs on ordering certificates from commercial CAs. The usage of a mini-CA will be illustrated by command-line examples.

We are going to cover the following topics in this chapter:

• Understanding the openssl ca subcommand
• Generating a root CA certificate
• Generating an intermediate CA certificate
• Generating a certificate for a web server
• Generating a certificate for a web and email client
• Revoking certificates and generating CRLs
• Providing certificate revocation status via OCSP

Technical requirements

This chapter will contain commands that you can run on a command line. You will need the openssl command-line tool and the OpenSSL dynamic libraries.

We will use many configuration files and commands in this chapter. Those configuration files and commands, saved as Shell scripts, can be found here: https://github.com/PacktPublishing/Demystifying-Cryptography-with-OpenSSL-3/tree/main/Chapter12.

Understanding the openssl ca subcommand

The openssl ca subcommand can be useful for running a mini-CA inside an organization. This kind of CA can, for instance, issue certificates for internal servers. Using an internal CA saves costs compared to using an external commercial CA. But it is not the only advantage. Many internal servers should not be exposed to access from the internet. This limitation hinders automatic server checks from the external CAs, which are needed to issue cheap or free certificates. Also, in some cases, it is undesirable to expose knowledge about the existence or name of the internal servers. When ordering a certificate from an external CA, you have to expose the internal server’s name to the CA. Furthermore, the CA may publish the certificate information to a Certificate Transparency (CT) log, leading to even more unwanted information exposure about the company’s internal servers.

Another reason to have an internal CA is to issue client certificates...

Generating a root CA certificate

We will create some needed directories and files and then proceed with generating the root CA certificate:

1. First, we will make the mini-ca directory where we will put all our CA-related files:

   $ mkdir mini-ca
   $ cd mini-ca

2. Inside the mini-ca directory, we will create the root directory for the files related to the root CA:

   $ mkdir root
   $ cd root

3. Inside the root directory, we will create a directory for issued certificates, a certificate index file, and a CRL number file:

   $ mkdir issued
   $ echo -n >index.txt
   $ echo 01 >crlnumber.txt

4. Now, we have to make a config file for our root CA; we will name this file root.cnf. We will start the config file with some mandatory parameters:

   [ca]
   default_ca = CA_default
   [CA_default]
   database                = index.txt
   new_certs_dir           = issued
   certificate...

Generating an intermediate CA certificate

Generating an intermediate CA certificate will be similar to generating a root CA certificate. We will use another directory for our intermediate CA; let’s call the directory intermediate and place it at the same level as the root directory inside the mini-ca directory:

1. Let’s create the intermediate directory and initialize it with the needed files and subdirectory:

   $ cd mini-ca
   $ mkdir intermediate
   $ cd intermediate
   $ mkdir issued
   $ echo -n >index.txt
   $ echo 01 >crlnumber.txt

2. Now, we have to make a config file for our intermediate CA; we will name this file intermediate.cnf. The config file for the intermediate CA will be similar to that of the root CA. We will start the config file with the same parameters as in the root CA configuration:

   [ca]
   default_ca = CA_default
   [CA_default]
   database                = index.txt
   new_certs_dir&...

Generating a certificate for a web server

The next certificate that we will generate is a certificate for a web server. As for the previous certificates, we will make a separate directory and a config file for this certificate:

1. However, as we are going to issue a leaf certificate, we will not need to create CA-related files in its directory. We will just need to create the directory and change our current directory there:

   $ cd mini-ca
   $ mkdir server
   $ cd server

The server certificate config file will be much shorter than the previously made CA certificate config files:

[req]
prompt                  = no
distinguished_name      = distinguished_name_server_cert
req_extensions          = v3_server_cert
[distinguished_name_server_cert]
countryName         &...

Generating a certificate for a web and email client

Generating a client certificate is similar to generating a server certificate:

1. As usual, we will make a separate directory for this certificate and change our current directory there:

   $ cd mini-ca
   $ mkdir client
   $ cd client

2. We will use the following configuration saved in the client.cnf file for generating the client certificate:

   [req]
   prompt                  = no
   distinguished_name      = distinguished_name_client_cert
   req_extensions          = v3_client_cert
   [distinguished_name_client_cert]
   countryName             = NO
   stateOrProvinceName     = Oslo
   localityName            = Oslo
   organizationName  ...

Revoking certificates and generating CRLs

Before revoking a certificate, we must issue it first. Let’s issue a sample certificate, similar to how we did so before:

1. As usual, the first step is to make a directory for the certificate files:

   $ cd mini-ca
   $ mkdir server2
   $ cd server2

2. Next, make the following certificate configuration and save it to the server2.cnf file:

   [req]
   prompt                  = no
   distinguished_name      = distinguished_name_server_cert
   [distinguished_name_server_cert]
   countryName             = NO
   stateOrProvinceName     = Oslo
   localityName            = Oslo
   organizationName        = TLS Experts
   commonName      ...

Providing certificate revocation status via OCSP

To serve OCSP responses, we have to sign them. An OCSP response for a certificate can be signed by its issuer certificate. The same issuer can also issue another certificate for signing OCSP requests. That certificate must have OCSPSigning included in the X509v3 extendedKeyUsage extension.

When we created the intermediate CA config file, we included the following X509v3 extensions section:

[v3_ocsp_cert]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning
crlDistributionPoints = URI:http://crl.tls-experts.no/intermediate_crl.der
authorityInfoAccess = OCSP;URI:http://ocsp.tls-experts.no/

That X509v3 extensions section will help us to generate a certificate for an OCSP responder. Let’s make this certificate:

1. As usual, we will start by preparing the directory:

   $ cd mini-ca
   $ mkdir...

Summary

In this chapter, we learned how to run a mini-CA. First, we learned about why a mini-CA can be useful within an organization. We also learned about the openssl ca subcommand and how to make configuration files for it. Then, we learned how to issue certificates using openssl ca. After that, we learned how to revoke certificates and issue CRLs. We finished the chapter by learning how to issue a certificate for an OCSP responder and how to provide certificate revocation status via OCSP using the openssl ocsp subcommand. This knowledge can help you to set up and run a mini-CA, gaining control over PKI in your organization.

This was the last chapter of the book. I hope that you have enjoyed both the chapter and the book, and have learned something new and useful. I also hope that the knowledge gained will help you to understand cryptographic and network security technologies better, develop more secure applications, and advance your career.