Skip to main content
LEAP Docs
Gitlab Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. Welcome to the LEAP documentation!
  2. /
  3. Tutorials
  4. /
  5. tls-certificates
Edit page

tls-certificates

Public Key Infrastructure

Podlily uses a dual certificate infrastructure for secure communication between clients and VPN gateways.

Provider CA (provider_ca)
├─── Provider's OpenVPN PKI root cerificate
└─── Signs → OpenVPN Gateway Server Certificate (gateway.crt)

Gateway Certificate (gateway.crt)
└─── used to verify to client that the gateway is part of the Provider OpenVPN PKI

Client CA (menshen_ca)  
├── Signs → VPN Client Certificate #1
└── Signs → VPN Client Certificate #2...

OpenVPN public key infrastrcuture setup

The following section is adapted from https://openvpn.net/community-docs/setting-up-your-own-certificate-authority--ca--and-generating-certificates-and-keys-for-an-openvpn-server-and-multiple-clients.html.

OpenVPN supports bidirectional authentication based on certificates, meaning that the OpenVPN client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established.

Both server and client will authenticate the other by first verifying that the presented certificate was signed by the correct certificate authority (CA), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server).

LEAPs OpenVPN PKI consists of:

  • A certificate (also known as a public key) and private key for the server.

  • A certificate and private key for each client

  • A root certificate authority (CA) certificate and key which is used to sign each of the server certificates. In Podlily this CA is the Provider CA

  • a secondary certificate authority authority (CA) which is used to sign each client certificate. In Podlily this CA is the Client CA

This security model has a number of desirable features from the VPN perspective:

  • The server only needs its own certificate/key — it doesn’t need to know the individual certificates of every client which might possibly connect to it.

  • The server will only accept clients whose certificates were signed by the client CA certificate. And because the server can perform this signature verification without needing access to the CA private key itself, it is possible for the Provider CA key (the most sensitive key in the entire PKI) to reside offline on a completely different machine.

  • The client certificate issuing CA needs to reside online and has to be available to the menshen service to generate on API request VPN client certificates.

  • Trust is established when the client validates the gateway’s certificate chain against provider_ca.crt, which the client has a local copy of. Mutual authentication completes when the gateway verifies the client certificate against menshen_ca.crt. The latter is passed to openvpn’s server process as a certificate bundle consisting of provider_ca.crt and menshen_ca.crt via the openvpn flag --ca.

  • If a private key is compromised, it can be disabled by adding its certificate to a CRL (certificate revocation list). The CRL allows compromised certificates to be selectively rejected without requiring that the entire PKI be rebuilt.

  • Theoretically, the server could enforce client-specific access rights based on embedded certificate fields, such as the Common Name. However this feature is not used in LEAP’s OpenVPN stack.

Certificate Types and Their Purposes

1. Private Root CA (provider_ca.crt, provider_ca.key)

Purpose: Signs OpenVPN server certificates of OpenVPN gateways. This CA’s private key should be kept offline after initial setup.

Creation: Generated in scripts/gen-provider-certs.sh. The subject of the certificate can be manually set and defaults to “CN=Provider Root CA”.

Usage: Signs server certificates for OpenVPN gateways during deployment. The public provider_ca.crt is served at <providerdomain>/ca.crt which clients need to fetch in order to verify the server when creating a VPN connection. LEAP’s VPN clients can also preship the ca.crt.

2. Client CA (menshen_ca.crt, menshen_ca.key)

Purpose: Signs certificates for OpenVPN clients (Bitmask or vanillla OpenVPN CLI) that are used to authenticate against the VPN gateways.

Creation: Generated by the script in scripts/gen-provider-certs.sh script with default subject “CN=Provider Root CA” if no alternative subject is provided by you.

Usage: Menshen uses it to sign individual client certificates for OpenVPN authentication. OpenVPN gateways verify client certificates against this CA. Served at /5/openvpn/cert and optionally at /3/cert if API v3 is supported.

Certificate distribution notes

Gateway (OpenVPN) nodes receive both CA certificates menshen_ca.crt and provider_ca.crt via the gateway_bundle.crt bundle.

Clients obtain only the Provider Root CA (provider_ca.crt) from menshen (at <providerdomain>/ca.crt), which they use to validate gateways.