Set Up and Configure a Certificate Authority

How To Set Up and Configure a Certificate Authority (CA)

Introduction

A Certificate Authority (CA) is an organization tasked with issuing digital certificates for verifying online identities. While public CAs are widely used for validating the identities of publicly accessible websites and services, private CAs are typically employed for closed groups and private services.

Setting up a private Certificate Authority allows you to configure, test, and run programs that require secure connections between clients and servers. With a private CA, you can issue certificates for users, servers, or specific programs and services within your infrastructure.

Certain Linux programs, such as OpenVPN and Puppet, utilize their private CAs. You can also configure your web server to use certificates issued by a private CA, ensuring that your development and staging environments mirror production servers by employing TLS encryption for secure connections.

In this guide, we will walk through the process of establishing a private Certificate Authority on an Ubuntu 20.04 server. You will learn how to generate and sign a test certificate using your new CA. Additionally, you'll discover how to import the CA server’s public certificate into your operating system’s certificate store, allowing you to verify the trust chain between the CA and remote servers or users. Finally, you`ll explore the process of revoking certificates and distributing a Certificate Revocation List (CRL) to ensure that only authorized users and systems can access services relying on your CA.

Prerequisites

To complete this tutorial, you will need:

Access to an Ubuntu 20.04 server to host your CA server.
A non-root user account with sudo privileges, which you should configure before starting this guide. You can follow our Ubuntu 20.04 Initial Server Setup guide to set up a user with appropriate permissions. This guide also includes firewall setup, which is assumed to be in place throughout this tutorial.
Ensure that the CA Server operates as a standalone system dedicated to importing, signing, and revoking certificate requests. It should not run any additional services, and ideally, it should be offline or powered down when not actively used for CA-related tasks.

Note: The last section of this tutorial is optional and focuses on signing and revoking certificates. If you choose to complete these practice steps, you will require a second Ubuntu 20.04 server or an alternative local Linux machine running Ubuntu, Debian, or related distributions.

Step 1 - Installing Easy-RSA

The first task in this tutorial is to install the easy-rsa set of scripts on your CA Server. easy-rsa is a Certificate Authority management tool used to generate a private key and public root certificate, which are essential for signing requests from clients and servers relying on your CA.

Log in to your CA Server using the non-root sudo user created during the initial setup and run the following commands:

sudo apt update
sudo apt install easy-rsa

You will be prompted to download and install the package. Confirm the installation by typing y.

At this point, you have successfully installed Easy-RSA, setting the stage for creating a Public Key Infrastructure (PKI) directory for your CA.

Step 2 — Preparing a Public Key Infrastructure Directory

With Easy-RSA installed, the next step is to create a skeleton Public Key Infrastructure (PKI) on your CA Server. Ensure you are still logged in as your non-root user and create an easy-rsa directory without using sudo:

mkdir ~/easy-rsa

This command will create a new easy-rsa directory in your home folder, which you'll use to create symbolic links pointing to the Easy-RSA package files installed in the previous step. These files are located in the /usr/share/easy-rsa folder on the CA Server.

Create the symbolic links using the ln command:

ln -s /usr/share/easy-rsa/* ~/easy-rsa/

Please note that this tutorial adopts a symlink approach rather than copying the Easy-RSA package files into your PKI directory. This ensures that any updates to the Easy-RSA package will automatically apply to your PKI`s scripts.

To restrict access to your new PKI directory, make sure only the owner can access it using the chmod command:

chmod 700 ~/easy-rsa

Finally, initialize the PKI inside the easy-rsa directory:

cd ~/easy-rsa
./easyrsa init-pki

You will receive an output indicating the initialization is complete and specifying the directory path for your newly created PKI. With this, you have set up a directory containing the necessary files to create a Certificate Authority.

Step 3 - Creating a Certificate Authority

Before generating your CA's private key and certificate, you need to create and configure a vars file with default values. This file is essential for customizing your CA's information. Navigate to the easy-rsa directory and create or edit the vars file:

cd ~/easy-rsa
nano vars

Paste the following lines into the file and modify the highlighted values to match your organization`s information. Ensure that no fields are left blank:

~/easy-rsa/vars
set_var EASYRSA_REQ_COUNTRY    "HU"
set_var EASYRSA_REQ_PROVINCE   "Pest"
set_var EASYRSA_REQ_CITY       "Budapest"
set_var EASYRSA_REQ_ORG        "Cherubits"
set_var EASYRSA_REQ_EMAIL      "administrator@cherubits.com"
set_var EASYRSA_REQ_OU         "Operation"
set_var EASYRSA_ALGO           "ec"
set_var EASYRSA_DIGEST         "sha512"

Once you've made the necessary changes, save and close the file. If you're using the nano text editor, press CTRL+X, then Y, and ENTER to confirm.

You are now ready to build your CA. Create the root public and private key pair for your Certificate Authority by running the following command:

./easyrsa build-ca

During this process, you'll be asked to enter a passphrase for your key pair. Ensure you choose a strong passphrase and store it securely, as you will need it for any interactions with your CA, such as signing or revoking certificates. You`ll also be prompted to confirm the Common Name (CN) for your CA. The CN is the name used to refer to this machine within the context of the Certificate Authority. You can simply press ENTER to accept the default name for simplicity.

Once complete, you will have two crucial files: ca.crt and ca.key. ca.crt is your CA's public certificate file, which all users, servers, and clients relying on your CA must possess. ca.key is the private key that your CA uses to sign certificates for servers and clients. It's crucial to keep ca.key secure, ideally only on your CA machine, and to ensure the CA machine is offline when not signing certificate requests for added security.

(Optional) — Signing a CSR

In the previous step, you created a practice certificate request and key for a fictional server. You then copied it to the /tmp directory on your CA server, simulating the process for real clients or servers sending CSR requests for signing.

In the fictional scenario, the CA Server must import the practice certificate and sign it. When a certificate request is validated by the CA and sent back to a server, clients trusting the Certificate Authority can also trust the newly issued certificate.

Since you're operating within the CA`s PKI where the easy-rsa utility is available, these steps use the easy-rsa utility for simplicity, instead of directly using openssl as done in the previous example.

The first step is to import the certificate request using the easy-rsa script:

cd ~/easy-rsa
./easyrsa import-req /tmp/sammy-server.req sammy-server

This will import the request with a short name, sammy-server. Next, sign the request using the easy-rsa script with the sign-req option, specifying the request type (server in this case) and the Common Name (CN) from the CSR:

./easyrsa sign-req server sammy-server

You will be asked to verify that the request comes from a trusted source. Type yes and press ENTER to confirm. After completing these steps, you will have signed the sammy-server.req CSR using the CA Server’s private key. The resulting sammy-server.crt file contains the practice server’s public encryption key, along with a new signature from the CA Server.

To distribute the new certificate to the remote server that made the CSR request, you can use scp as follows:

scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp

At this point, you can use the issued certificate with services such as a web server, VPN, configuration management tool, database system, or for client authentication.

(Optional) - Revoking a Certificate

Occasionally, you may need to revoke a certificate to prevent a user or server from using it. The general process for revoking a certificate involves:

Revoking the certificate with the ./easyrsa revoke client_name command.
Generating a new Certificate Revocation List (CRL) with the ./easyrsa gen-crl command.
Transferring the updated crl.pem file to the servers or systems relying on your CA, copying it to the required directories for programs referring to it.
Restarting any services using your CA and the CRL file.
This process can be used to revoke any certificates previously issued at any time. Below are detailed instructions for each step:

Revoking a Certificate

To revoke a certificate, navigate to the easy-rsa directory on your CA server:

cd ~/easy-rsa

Next, run the easyrsa script with the revoke option, followed by the client name you wish to revoke. For instance, using the practice example sammy-server:

./easyrsa revoke sammy-server

You will be prompted to confirm the revocation by typing yes.

Generating a Certificate Revocation List (CRL):
Now that you've revoked a certificate, it`s essential to update the list of revoked certificates on your CA server. This ensures you can determine which users and systems have valid certificates in your CA.

To generate a CRL, run the easy-rsa command with the gen-crl option while still in the easy-rsa directory:

./easyrsa gen-crl

If you used a passphrase when creating your ca.key file, you will be prompted to enter it. The gen-crl command will generate a file called crl.pem, containing the updated list of revoked certificates for your CA.

Next, you need to transfer the updated crl.pem file to all servers and clients that rely on this CA each time you run the gen-crl command. Otherwise, clients and systems will still be able to access services and systems using your CA, as those services need to know about the revoked status of the certificate.

Transferring a Certificate Revocation List:
To transfer the crl.pem file to your servers, you can use the scp command. Ensure you are logged into your CA server as your non-root user and run the following, substituting your server`s IP or DNS name:

scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

Now that the file is on the remote system, the last step is to update any services with the new crl.pem file.

Updating Services that Support a CRL

The steps required to update services that use the crl.pem file are service-specific and are beyond the scope of this tutorial. In general, you will need to copy the crl.pem file to the location where the service expects it and then restart the service, often using systemctl.

Once you've updated your services with the new crl.pem file, your services will be able to reject connections from clients or servers using a revoked certificate.

Examining and Verifying the Contents of a CRL:
If you want to examine a CRL file, for example, to confirm a list of revoked certificates, you can use the following openssl command from within your easy-rsa directory on your CA server:

cd ~/easy-rsa
openssl crl -in pki/crl.pem -noout -text

This command displays the contents of the CRL file. You can also run this command on any server or system that has the openssl tool installed, with a copy of the crl.pem file. For example, if you transferred the crl.pem file to your second system and want to verify that the sammy-server certificate is revoked, you can use an openssl command like this:

openssl crl -in /tmp/crl.pem -noout -text | grep -A 1 8348B3F146A765581946040D5C4D590A

Replace the highlighted serial number with the one you noted during the revocation step. This command allows you to verify the contents of your Certificate Revocation List on any system relying on it to restrict access to users and services.

Conclusion

In this tutorial, you created a private Certificate Authority (CA) using the Easy-RSA package on a standalone Ubuntu 20.04 server. You learned how the trust model works between parties relying on the CA, created and signed a Certificate Signing Request (CSR) for a practice server, and learned how to revoke a certificate. You also learned how to generate and distribute a Certificate Revocation List (CRL) to ensure that only authorized users and systems can access services relying on your CA.

With your private CA, you can issue certificates for users and use them with services like OpenVPN. You can configure development and staging web servers with certificates to secure your non-production environments, helping ensure that your code and environments closely match your production environment.

If you want to delve deeper into using OpenSSL, you can explore our tutorial on "OpenSSL Essentials: Working with SSL Certificates, Private Keys, and CSRs," which provides additional information on OpenSSL fundamentals.