Roman Bezlepkin’s Website

HomeLab Reverse Proxy - Part 2 - Certificate Management

This is a series of articles about running a reverse proxy; stay tuned via RSS when more parts will be published.

In this part, we will be preparing certificates for our OpenVPN server and reverse proxy client.


OpenVPN supports many methods to authenticate clients such as username/password pair, certificates, or both. In my case, I am using just certificate authentication with unique certificate and private key issued to (each) reverse proxy VM. In a case where more privileged access is required, I suggest exploring both certificate and username/password authentication.

When a client connects, the client will present a certificate to identity itself. In order for the OpenVPN server to validate it, the certificate must be issued by a Certificate Authority (CA) OpenVPN can trust. Running CAs is a complicated subject is beyond the scope of this article, but for sake of our homelab, we can create a simple CA for our needs and take care to keep the CA part itself secret.

Note: pfsense can provide self-signed certificates itself without you having to run a custom CA and issuing certificates.

For CA management, I found xca to be easy to use, but a lot of this can be adopted with scripts for OpenSSL CLI for example.

Creating a CA

Our CA will handle issuing & signing client certificates used by VPN clients but also the certificate used by OpenVPN server (to identify itself).

In xca, begin first by creating a new database, giving it a strong password (use a password manager to generate & store one), and hitting that New Certificate button.

New CA creation Our internal CA. Important fields are commonName and Internal Name, the rest can be nonsense.

Be sure to create a strong private key, in this case I am using a RSA 2048-bit key as bare minimum. Best practice is to use a dedicated computer without internet connectivity and a secure/hardened OS to perform CA operations. One person I know uses an old ThinkPad with tails and a hardware-encrypted USB flash drive to do this.

Next, over on Extensions I defined X509v3 type as “Certification Authority” and checking the “Critical” box. In terms of Validity, I try to keep CAs valid for 10 years, with intermediate CAs valid 5 years and finally with server/client certificates valid for one year. In a lab/personal environment I see no reason to make really short time range unless you want more work remembering and rotating certificates :-).

New CA extensions X509 Extensions, minimum necessary for our CA.

Next, on Key Usage, we just need to be able to sign certificates (Certificate Sign) we create and later, sign Certificate Revocation Lists for revoking certificates.

New CA key usage Certificate Sign, CRL Sign selected

Newly created CA in the list Newly created CA appears in the list

Our CA has now been created and we can start issuing server and client certificates with it. At this point it might be worth to investigate creating a Certificate Revocation List (CRL), perhaps I might explore that in a later article.

Server Certificate

Our OpenVPN Server needs a certificate it will present to clients to identify itself. In xca, we can create a new certificate that will be signed by our CA by right-clicking on the CA and selecting New from the menu option.

New server certificate Be sure that our CA is selected for signing.

Much like our CA, the Subject information does not change much except for a descriptive Internal Name (for our reference), but now — the commonName has to be special. Typically commonName refers to a fully-qualified domain name used by a service both running behind that host name and serving this certificate. At this point, let’s assume that clients will be connecting to our OpenVPN server at (more on that later).

Just like for our CA, be sure to generate a new and unique private key.

OpenVPN server certificate subject commonName here refers to the FQDN where clients will be connecting to and is usually checked by an algorithm to match with what is defined by the certificate

Now for the server, we no longer want it to be a Certificate Authority and instead — an End Entity. I’ve also enabled both Subject Key Identifier and Authority Key Identifier this time along with giving the certificate a shorter time to be valid (5 years).

OpenVPN server certificate extensions

OpenVPN server expects1 the following Key Usage for a X509v3 Certificate:

Additionally, extended key usage must allow for TLS Web Server Authentication.

OpenVPN server certificate key usage Required key usage selected for the server certificate

OpenVPN server certificate created Server certificate now appears under the CA certificate

Client Certificate

Now that we have a CA and a server certificate, it’s time to create a client certificate. The process is very similar to the server certificate with a few changes.

I typically pick the computer name as the commonName for a client certificate used by OpenVPN. This helps identify the specific machine that connects to a network and we will later customize it further by the common name (such as setting a “static” IP address).

Thus, if our VM name will be rp10, then our commonName should also be rp10. As always, generate a new unique private key for this certificate.

OpenVPN client certificate subject As before, the subject identifies the certificate. Note that the commonName is different.

OpenVPN client certificate extensions Client certificate extensions aren’t that much different from its server certificate brother, except maybe with less time to live (expiration).

Finally the difference with a server certificate is that the client only requires Digital Signature (X509v3 Key Usage) and TLS Web Client Authentication (X509v3 Extended Key Usage).

OpenVPN client certificate key usage

OpenVPN client certificate created Our new certificates are ready to be implemented

Continue to Part 3 − setting up an OpenVPN server.

  1. This information is based on what OpenVPN’s easy-rsa generates.