Learn L2TP IPsec - Certificate Management (CA, CRL, OCSP)

#Introduction

In episode 6 we chose X.509 certificates as the enterprise authentication. Episode 16 puts it into practice: how to build a CA hierarchy, issue certificates for servers and clients, revoke problematic certificates, and make sure the whole process runs automatically.

Certificates are the foundation of trust: the entire security of your deployment depends on a well-guarded CA and a correct revocation process. After this episode, you can manage digital identities for thousands of clients without sharing a single common secret.

#The CA Hierarchy

#Root CA, Intermediate CA, and Leaf

A correct certificate hierarchy is layered: the Root CA (offline, tightly guarded) issues the Intermediate CA used day-to-day, and the intermediate issues leaf certificates for servers and clients. This layering limits risk: if the intermediate leaks, you simply replace it without touching the root.

Root CA (offline)
  -> Intermediate CA (operasional)
       -> Server cert (vpn.example.com)
       -> Client cert (user-1, user-2, ...)

This model also makes rotation and revocation easier, because a short chain speeds up validation.

#Building a CA with OpenSSL

#Root and Intermediate

We can build the entire hierarchy with OpenSSL. First, create the Root CA:

openssl genrsa -out rootCA.key 4096
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 \
  -out rootCA.crt -subj "/CN=VPN Root CA"

The openssl req -x509 command self-signs the root certificate with a 10-year validity. Store rootCA.key offline — it is the most valuable key in the entire system.

Then issue the Intermediate CA from the Root:

openssl genrsa -out intermediate.key 4096
openssl req -new -key intermediate.key -subj "/CN=VPN Intermediate CA" \
  -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA rootCA.crt -CAkey rootCA.key \
  -CAcreateserial -out intermediate.crt -days 1825 -sha256

#Issuing Leaf Certificates

#pki for strongSwan

strongSwan provides the pki tool that simplifies issuing:

sudo pki --issue --cacert intermediate.crt --cakey intermediate.key \
  --san vpn.example.com --san 203.0.113.10 \
  --lifetime 365 --dn "CN=vpn.example.com" \
  --outform pem > server.crt
sudo pki --gen --type ecdsa --outform pem > server.key

pki --issue issues a leaf certificate with subject alternative names (SANs) containing the server's domain and IP. The server key pair is created separately with pki --gen.

#certutil for Libreswan

Libreswan stores certificates in the NSS database, so use certutil:

sudo certutil -A -d sql:/etc/ipsec.d -n "Root CA" -t "CT,," -i rootCA.crt
sudo certutil -A -d sql:/etc/ipsec.d -n "Intermediate" -t ",," -i intermediate.crt
sudo certutil -A -d sql:/etc/ipsec.d -n "server-cert" -t ",," -i server.crt
sudo pk12util -d sql:/etc/ipsec.d -i server.p12 -W "password-pkcs12"

pk12util imports the key pair and certificate in a single PKCS12 file. After that, authby=rsasig with leftcert=server-cert will use this identity.

#Revocation: CRL and OCSP

#Two Ways to Revoke

When a client key leaks, its certificate must be revoked. There are two mechanisms: CRL (Certificate Revocation List), distributed as a list, and OCSP, which answers per-certificate questions in real time. For IPsec, include the CRL distribution point or OCSP in the certificate when issuing, then enable the check in the daemon.

Libreswan checks CRLs distributed via URL, while strongSwan provides the revocation and ocsp plugins. A minimal strongSwan configuration:

charon {
    plugins {
        revocation {
            enable = yes
            crl_uri = "http://crl.example.com/vpn.crl"
        }
    }
}

The crl_uri value points to a CRL file that is republished periodically.

#Monitoring Validity

#Automation and Alerts

Expired certificates are the most common cause of VPN downtime. Automate the monitoring:

for c in *.crt; do
  openssl x509 -in "$c" -noout -enddate
done

The loop above prints the expiry date of every certificate in the directory. Set up a cron job that runs it weekly and sends an alert when less than 30 days remain.

#Closing

Episode 16 completed the certificate foundation: a layered CA hierarchy that limits risk, issuing with OpenSSL, pki and certutil, revocation handling through CRL and OCSP, and automated validity monitoring.

Key takeaways:

• Root CA offline, intermediate operational, leaf for servers and clients.
• pki --issue for strongSwan; certutil and pk12util for Libreswan NSS.
• SANs must contain the domain and IP so identities match.
• CRL for a static list, OCSP for real-time status.
• A revoked certificate can no longer be used after revocation.
• Monitor validity weekly and renew before expiry.

In the next episode, episode 17, we will discuss virtual IP and address management — client address allocation via IKEv1 ModeConfig or IKEv2 Configuration Payload, the rightsourceip column, and integrating dynamic allocation with RADIUS.