← Integrations

Automated SSL certificate renewal for OpenVPN

OpenVPN only reads its certificate at startup. CertKit swaps it and restarts the server for you.

OpenVPN Community Edition loads its server certificate from the cert and key directives in the server config when the service starts. OpenVPN Access Server keeps its web certificate in its configuration database. A renewed certificate does nothing until someone copies it into place, updates the config, and restarts the service. For a public certificate, that's every 47 days.

CertKit issues and renews the certificate centrally. The CertKit Agent on the OpenVPN host installs it, restarts OpenVPN, and checks that it started cleanly. On Access Server it also confirms the web port serves the new certificate.

Start free trial Watch demo

Built for OpenVPN

Pre-built templates for OpenVPN Community Edition on Linux and Windows, and for the OpenVPN Access Server web certificate, ship in your CertKit account.

For OpenVPN Community Edition, the agent writes the certificate, its chain, and the key next to the server config, points the cert and key directives at them, and restarts the service. Inline <cert> and <key> blocks are replaced too. If OpenVPN fails to start on the new certificate, the agent puts the previous config and files back and restarts it again.

For OpenVPN Access Server, the agent installs the certificate for the Admin Web UI and Client Web UI with sacli. Only the web service restarts, so connected VPN sessions stay up. The internal CA that Access Server uses for the VPN tunnel isn't touched.

A Community Edition restart drops connected clients for a moment, and they reconnect on their own. Set a deployment window so that happens overnight instead of in the middle of the workday.

How to install a new server certificate on OpenVPN

The manual process, if you want to do it yourself:

  1. Renew the server certificate. With Easy-RSA, run ./easyrsa renew server. Easy-RSA 3.2.0 alone dropped renew, so on that version you run ./easyrsa expire server and then ./easyrsa sign-req server server. For a public certificate, send a certificate request (CSR) to the CA and keep the intermediates it returns.
  2. Copy it next to the server config. That's /etc/openvpn/server/ on most Linux installs and C:\Program Files\OpenVPN\config-auto on Windows. The private key must be unencrypted, so keep it readable by root only.
  3. Update the cert and key directives. Point cert and key in server.conf or server.ovpn at the new files, or paste them into the inline <cert> and <key> blocks. Intermediates go after the server certificate in the same file, or in extra-certs.
  4. Restart OpenVPN. Run systemctl restart openvpn-server@server, or restart the OpenVPNService service on Windows. A reload can't read a root-only key once the server has dropped privileges with user nobody. Check the log for "Initialization Sequence Completed".
  5. On Access Server, use the Admin Web UI. In Access Server 3, open Certificate Management → Web Server Certificate, turn on Use your own certificate, upload the Web certificate, Private key, and CA bundle, then Save and Restart. Older versions use Configuration → Web Server and Update Running Server.

Every one of these steps is manual, and OpenVPN won't repeat any of them when the certificate renews. With public certificate lifetimes shrinking to 47 days, that's twelve times a year, on every VPN server. Miss one and clients fail with VERIFY ERROR: depth=0, error=certificate has expired, and remote workers can't connect.

At 47 days, automation is the only sustainable way to run OpenVPN certificates. Here's how CertKit does it.

CertKit has been a fantastic solution for automating our environment’s SSL/TLS certificates. With a single pane of glass for centralized management, visibility, and monitoring and the highly customizable interface for granular control over individual systems, we have found great value in reducing the time and complexity of managing an ad-hoc ACME solution for individual certificate automation.

Seth Allums, Lead Systems and Information Security Engineer, Clackamas Community College

How it works

 Your OpenVPN host        CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └────────────────│DNS│
│ Config      ◄─┘ │ │                      └───┘
│ [x] Updated     │ │
│                 │ │
│ OpenVPN     ◄───┘ │
│ [x] Restarted     │
│ [x] Started       │
└───────────────────┘

CertKit issues and renews certificates centrally using delegated DNS validation. You create a one-time CNAME record, and CertKit handles every ACME challenge after that.

The agent runs on the OpenVPN host itself and pulls each renewal from CertKit over outbound HTTPS. After the restart, it reads the OpenVPN log or probes the Access Server web port before it reports success. The VPN server never runs ACME and never holds DNS credentials.

What CertKit handles

Setup takes about ten minutes

  1. Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit, or issue from a CertKit private CA.
  2. Install the CertKit Agent on the OpenVPN host. One command. It runs as root on Linux and with administrator rights on Windows, because it edits the server config and restarts the service.
  3. Add the OpenVPN deployment script. Choose OpenVPN Community Edition Server or OpenVPN Access Server: Web Services Certificate. A single server instance is found on its own. With several, set the config path in the Advanced view.
  4. Do the one-time prep. For Community Edition, add the new issuing root to your client profiles before the first deployment. For Access Server, turn off its built-in ACME client if you enabled it, so it doesn't replace the certificate CertKit installs.

See the full architecture →

OpenVPN deployment requirements and troubleshooting →

Why the first deployment needs your client profiles

An OpenVPN Community Edition client doesn't use the operating system's trust store. It trusts only the CA in its profile's ca file or <ca> block, which is usually the Easy-RSA CA that signed the original server certificate. Switch the server to a certificate from any other CA and every client fails verification until its profile changes.

Add the new root to the client ca before the first deployment. With a public root in there, also pin the server name with verify-x509-name. OpenVPN doesn't check the hostname, and remote-cert-tls server accepts any server certificate that root has signed. A CertKit private CA that signs only your VPN servers avoids that. After the switch, renewals from the same root need nothing on the clients.

Access Server avoids the issue. The template changes only the web certificate, and every VPN profile keeps trusting Access Server's internal CA.

OpenVPN is just one part of your remote access

Most organizations have more than one way in from outside: SSL VPN on firewalls like WatchGuard Firebox and SonicWall, and Microsoft Always On VPN gateways. CertKit automates the certificates on all of them from one account.

See all integrations

Start automating OpenVPN certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing