What is one of the most annoying tasks as a Network or Systems Engineer? Yep you got it, managing certificates.

Almost all modern ICT systems are managed using a web browser and via some sort of Javascript / HTML5 interface. The industry has moved to TLS/HTTPS by default which means all these web based systems need valid certificates or the browsers scream all sorts of errors and this is only going to get worse.

For internal networks managing a Certificate Authority can be a time consuming task. What if you could create your own CA with a long expiry option? Issue certs from it easily and not have to change certificates on Infrastructure every year. This can be acheived with EasyRSA. EasyRSA is a utility for X.509 based certificates that is part of the OpenVPN project but can also be used to create your own Certificate Authority. Here is a run down of the tasks for this project:

1. Create an Ubuntu VM with easy-rsa installed (can be any flavour of Linux, setting up the vm is out of scope). I recommend creating a secondary user to do all your ca config with that is not the root user.
2. Build the CA with easyrsa and issue 10 year root cert – which is the default:
sudo apt install easy
mkdir ~/easy-rsa
ln -s /usr/share/easy-rsa/* ~/easy-rsa/
chmod 700 /home/ca/easy-rsa/
cd ~/easy-rsa/
./easyrsa init-pki

2.1 Edit your variables for the CA including your cert expiry time:
nano vars
set_var EASYRSA_REQ_COUNTRY "US"
set_var EASYRSA_REQ_PROVINCE "Company State"
set_var EASYRSA_REQ_CITY "Company City"
set_var EASYRSA_REQ_ORG "Company.com"
set_var EASYRSA_REQ_EMAIL "adminuser@company.com"
set_var EASYRSA_REQ_OU "IT"
set_var EASYRSA_ALGO "ec"
set_var EASYRSA_DIGEST "sha512"
set_var EASYRSA_CA_EXPIRE 3650
set_var EASYRSA_CERT_EXPIRE "3258"
Note that CA_EXPIRE sets how long the CA cert is valid for. CERT_EXPIRE is how long issued certificates are valid for.

2.2 Build the CA and export root cert:
./easyrsa build-ca
Upon building you will be asked to input a CA password. Use a password generator and securely store this password. It goes without saying, if you loose your CA password you won’t be able to issue and sign requests for certificates.
cd pki/
cat ca.crt
Copy the output to a text file and save as ca.crt
3. Import the ca.crt to the trusted root store on your domain, pc or browser. For Windows it is the Local Machine > Trusted Root Certificate Store.
4. Now you can issue a certificate signing request for an Infrastructure device. To do so we will create a new key with openssl. In the below example we are issuing a web server certificate for a Riverbed HTTPS management interface:
cd ~/csr
openssl genrsa -out rb-demo.key
openssl req -new -key rb-demo.key -out rb-demo.req -config <( cat <<-EOF [req] default_bits = 2048 prompt = no default_md = sha256 req_extensions = req_ext distinguished_name = dn [ dn ] C=US ST=Company State L=Company Town O=Company.com OU=IT emailAddress=support@company.com CN = rb-demo.company.com [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = rb-demo.company.com EOF )

4.1 Lets import the above request and sign it with easyrsa:
./easyrsa import-req ../csr/rb-demo.req rb-demo
./easyrsa sign-req server rb-demo

4.2 Export your key and cert with your tool of choice for SCP, I use WinSCP.
The key will be in ~/csr. You can also cat the issued cert like so and copy the X509 output to a text file and name it file.crt:
cat ~/easy-rsa/pki/issued/rb-demo.crt

So there you have it, your own internal / private "Infrastructure CA". My next task with this is to create a shell script for issuing certificates and interacting with the CA, if I ever get around to it!