Web security
Stuart Burns walks through what certificates are, setting up a certificate server in your local network and how to use it.
Stuart Burns walks you through what certificates are, how to set up a certificate server running on your local network, and how to make use of it.
Certificates are a critical component of the internet today, so in this tutorial we’ll cover what certificates are, why they are so critical, how they can be used and how to make your own Certificate Authority (CA) to create them. We’ll be using a fully updated Ubuntu 20.04 LTS server to create a certificate server for your local network as well as a root certificate for distribution with Firefox. We’ll also cover creating and installing an SSL certificate for an example webserver (again, Ubuntu 20.04 LTS server). Both of these hosts should have static IP addresses. If you want to play along you should be able to ping both servers using their FQDN (Fully Qualified Domain Name).
A dead cert
So what is a certificate? A certificate is essentially verifiable proof that an item is what it purports to be. For example, a passport is proof of identity. We put faith in it because we trust that the Certificate Authority (the Passport Office) has vetted and verified the holder’s identity, and believe they are who they say they are and that the document (passport) is real.
The same principle applies to verifying identity on the internet. The difference is that the certificate is digital in nature and the certificates are digitally signed by the issuing authority using public key encryption. This means, all things being equal, that they cannot be easily forged or changed. Essentially a certificate provides assurance about the integrity of the item in question. On top of that, a webserver uses this certificate in setting up encryption between the website and the client.
There are several commercial certificate authorities including GoDaddy, Visa, DigiTrust and others. These vendors pay to include their public certificate in a browser – for example, Firefox. This means that any website signed by these signing authorities is automatically trusted. To see the range of certificates authorities your browser trusts, in Firefox for example, go to Preferences, search for ‘Certificates’ and then select View Certificates. You will certainly have heard of some of them but not others.
If you want to remove a certificate authority, just select the item in question, click ‘Distrust this certificate’ and it will be removed from the list. Exercise caution when removing a certificate, however, as it may prevent certain sites from working.
Without a doubt, the easiest way to install a basic certificate server for a home network is to use the easyrsa package included in the Ubuntu repository. Easy-rsa will do all the heavy lifting for the Certificate Authority creation. There should be a local DNS server configured so that we can properly resolve the servers in question and experiment with our certificates. Without further ado, install the easy-rsa package:
sudo apt-get install easy-rsa -y
Create a directory and link the easy-rsa to use our configuration:
cd && mkdir easy-rsa && ln -s /usr/share/easy-rsa/* ~/ easy-rsa
All the above has put in place the requirements to be able to build a root CA. The CA has several properties that must be configured in the root certificate, such as Country, City, Organisation name, email and others. These all need to be configured before the CA creation process is started. Out of the box, the vars.example (located in the easy-rsa folder) will need to be renamed to just vars:
cp easy-rsa/vars.example easy-rsa/vars
It is really important that the name is vars otherwise the deployment wont work as expected. Open the file:
vi easy-rsa/vars
To initialise the PKI infrastructure, use the following
command. It initialises the infrastructure for first use.
cd ~/easy-rsa
./easyrsa init-pki
Within the file there are several items that need to be uncommented and configured, substituting appropriate values as in this example:
set_var EASYRSA_REQ_COUNTRY “GB” set_var EASYRSA_REQ_PROVINCE “London” set_var EASYRSA_REQ_CITY “London” set_var EASYRSA_REQ_ORG “My super local CA company” set_var EASYRSA_REQ_EMAIL “me@myemail. local” set_var EASYRSA_REQ_OU “My Organizational
Unit” set_var EASYRSA_NS_COMMENT “My super local
CA” set_var EASYRSA_KEY_SIZE 2048 set_var EASYRSA_CERT_EXPIRE 365
Most of the settings are obvious. Once edited, save the file. These can be overridden on the command line if required (more information on easy-rsa can be found at https://easy-rsa.readthedocs.io/en/latest). Now is the time to run the process to build the root certificate server, using the command ./easyrsa build-ca . Note that there are several other options within the file but to keep it straightforward we are only including a subset of most often used. Other changeable values include the length of time the certificate is valid for, encryption schemes and other advanced settings.
The only question asked is the key phrase. This is the password that will be needed to create and revoke certificates for servers. Make sure it is secure and write it down somewhere safe, just in case. If the passphrase is forgotten the only option is to redo everything from the start! It is possible to bypass the password using nopass as an option specified on the build-ca
command, but this is not recommended for obvious reasons. Note that there seems to be an issue with using easy-rsa complaining it cannot find the .rnd file. If this error is thrown, use the following command from within the easy-rsa folder. This should fix this issue: dd if=/dev/urandom of=pki/.rnd bs=256 count=1
A matter of trust
It is important to understand how the certificate system works. At the top level of the tree is the root Certificate Authority (CA). As part of the easy-rsa CA setup it outputs a digitally signed root certificate (ca.crt) and the private key for the root ca (ca.key located in the pki/private folder). This signed certificate can then installed in web browsers. Once it is installed it signifies that the browser trusts our certificate authority and that by extension, any other certificates that we digitally sign. To install the root certificate is simple enough. Copy (by whatever means) the ca.crt file from the pki folder. Open Firefox and navigate to the settings option. Within the settings, click the ‘Privacy and security’ portion and scroll to the bottom where there is a Certificates section. Select ‘View Certificates’, clicking Import from the buttons at the bottom of the dialogue and select the file in question. When asked about how to trust this certificate select only ‘Trust this CA to identify web sites’.
This will need to be repeated for all clients that need to accept certificates signed by our new certificate server. You have a fully working CA server. At this moment our browser trusts us, but we trust no-one.
In order to start trusting the computers and devices on the network, a CSR or certificate signing request is needed. A CSR is a package of data formatted for submission to the Certificate Authority and if we chose to accept this request (as the CA owner), we sign the request with the CA private key and then send back the certificate for the approved server. This is the important bit of the CA’s role.
If the CA signs the request it is essentially extending its trust to the certificate owner. This is why CAs need to be extremely careful about validating and verifying the requests. To press home that point, not all certificates are created equal.
There are DV certs (to validate a domain), OV (used to validate organisations) and lastly EV (Extended Validation). Each one increases both the scrutiny, time and cost involved, but for example, financial
organisations would very much prefer to use EV because the level of checking and verification is that much more thorough and in-depth.
This tutorial is purely focusing on domain validation. In order to create the CSR there needs to be a copy of OpenSSL. It’s probably already installed but just in case:
sudo apt-get install openssl -y
Creating a certificate signing request consists of three separate steps. First, create a new private key.
mkdir signing && cd signing openssl genrsa -out webserver.key
After that we create the CSR using our newly created key (be sure to backup that key somewhere safe):
openssl req -new -addext “subjectAltName = webserver” -key webserver.key -out webserver.req
It is prudent to mention that there is more than one name for the server. For example webserver and webserver.mysite.local are two different entities as far as certificates are concerned.
The above command will ask a series of questions that need to be filled in. The important property is the Common Name. This is the FQDN (Fully Qualified Domain Name). If you get this wrong, it won’t work! It is possible to pass all these parameters to the openSSL
command directly rather than manually filling it in.
If you look at the request in a file editor it will appear to be nonsensical data, apart from the certificate start and certificate end statements. To view the information it contains (to verify it is correct) use the following:
openssl req -noout -text -in webserver.req
Now that the certificate signing request file has been generated (the webserver.req file) the next step is to copy the request to the CA server. Again, do this by any means but it’s just as easy to use the built-in scp
command. Shown below is an example of copying the file with scp:
scp ~/signing/webserver.req sysadmin@10.0.0.217:/ home/sysadmin/
Sign here please
All that remains is to import and sign the request with our CA key. It should be obvious that this key should be kept secure. It is acceptable for a local installation to just ‘hide’ it, but for commercial CAs the security concern is much greater, given the havoc that could be released if it was lost.
The following should be done on the certificate server. The first step is to import the request into the database that easy-rsa created earlier. At the risk of stating the obvious, below, the import request takes the format of a filename and the second variable is a name that gets recorded in the CA database. The following needs to be done on the CA server. cd ~/easy-rsa
./easyrsa import-req /home/sysadmin/webserver.req webserver
At this point the request has been imported. All that remains is to sign the request (approve it in other words). Do this by using the following command. Don’t conflate the server and webserver items, the first server identifies what type of signing is being performed, in our case server signing.
./easyrsa sign-req server webserver
All being well, the newly created certificate will have been created and placed in the /issued folder of the easy-rsa CA folder.
That fully signed request can now be passed back for inclusion in the webserver. To copy it back to the home folder on the webserver use scp: scp ~/home/easy-rsa/pki/issued/webserver.crt sysadmin@webserver:/home/sysadmin/
Adding it into an example Apache server is next. Install Apache sudo apt-get install apache2 -y . It is important to note that any private key that is used with Apache (or any other web server software) needs to have no password. The reason for this is that if Apache tries to load that certificate it will wait until the password is provided, so if the server is rebooted, Apache will sit there and wait until the password is entered and the webserver won’t serve web pages.
Create a folder for the certificates and copy across the files required:
sudo mkdir /etc/apache2/certs sudo cp ~/signing/webserver.key /etc/apache2/certs/ sudo cp ~/webserver.crt /etc/apache2/certs/
To enable HTTPS for our webserver there is some background work that needs to be done. Firstly, enable SSL support for Apache:
sudo a2enmod ssl sudo systemctl restart apache2
Assuming Apache2 restarted successfully, the configuration file needs to be edited to reflect our change. Use nano to edit /etc/apache2/sitesenabled/000-default.conf sudo nano /etc/apache2/ sites-enabled/000-default.conf and modify it so it looks similar to the one below. Make a backup first, just in case there is a need to go back:
ServerAdmin webmaster@localhost
ServerName webserver DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined
ServerAdmin webmaster@localhost
ServerName webserver DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on SSLCertificateFile /etc/apache2/certs/webserver. crt
SSLCertificateKeyFile /etc/apache2/certs/ webserver.key
Create the folder certs and copy both the webserver. key file and the webserver.crt file into it. Restart the Apache2 service using:
sudo systemctl restart apache2
Now, using Firefox on one of the local computers that has the root certificate installed, browse to the webserver using the FQDN, substituting HTTP for HTTPS. If everything has worked it should now be possible to browse using HTTPS and seeing the little padlock icon indicating a secure connection.
At this point we have covered the basics of creating our CA and creating certificates and trusting them. In the real world certificates can be lost or compromised. That is where a CRL or certificate revocation list comes in. To revoke a certificate is straightforward. Implement it by using the following command (again, on the certificate server):
./easyrsa revoke webserver
The CRL works as part of the connection process. When a client is offered a certificate it checks the certificate against the CRL list that the CA maintains. If the certificate is revoked it will throw an error in the browser warning of this.
In summary, all being well you should now be able to create a certificate authority, install the root certificate, create and sign SSL certificates, install them in an Apache server and also revoke them as needed.