CA Certificate Management
Introduction
In the OpenVPN Access Server version 2.9 release we added the ability to support multiple CA certificates. This documentation provides you with the details for managing the certificates and user profiles for your VPN server. Also, we’ll explain how Access Server handles certificates and how the ability to manage multiple certificates addresses an issue with certificate expiration.
Managing CA certificates
Access Server 2.9 and newer includes the CA Management section in the Admin Web UI. You can use this section to generate a new set of certificates.
You can also refer to the user manual: Configuration: CA Management.
Managing user profiles
Along with the new CA Management section you’ll see a new User Profiles section in the Admin Web UI. While previous Access Server versions had a section to revoke certificates, that has been replaced by the User Profiles section because your users can now have multiple profiles. From the User Profiles page you can add, download, or delete user profiles as well as view information such as the signing CA and the expiration date.
Understanding CA management with Access Server
OpenVPN is based on SSL/TLS technology, in which clients and servers can verify each other’s identities using certificates. Certificate management is especially important to defend against man-in-the-middle attacks, where an attacker sitting between the VPN client and VPN server can attempt to redirect or capture the traffic, or dupe the user into divulging server credentials.
OpenVPN Access Server issues and manages its own certificates for the server and its clients. This certificate infrastructure is called public key infrastructure (PKI). Access Server automatically manages and provisions these certificates for you. Each certificate is valid for a certain period of time; by default this has been set to 10 years from the date you installed Access Server, although this is configurable.
OpenVPN Access Server 2.9 and newer includes two key features that aren’t available in previous versions. Namely, Access Server 2.9 and above automatically renews your existing CA each year, and enables you to generate a new CA with the cross-signing of the old CA. This allows your server to continue to allow connections from older clients, while also accepting new certificates that use more modern security practices. And, each new device can have its own certificate instead of a shared certificate for all devices for a particular user account.
Generating a new CA certificate also improves security. For example, 1024-bit RSA certificates were once considered secure, but now they are not. Therefore, all Access Server 2.9 and newer installations use 2048-bit RSA certificates.
Updating from 1024-bit RSA certificates to 2048-bit RSA certificates (or to elliptic curve certificates) on an existing installation would require a complete reset of your Access Server’s PKI structure. Such a change would also require installing new client configuration profiles on most if not all current VPN clients. On Access Server 2.9.0, you can set up a new CA alongside the old one and accept connections from both. This allows a graceful transition.
On older versions of Access Server, the CA certificates expire after ten years. Once expired, they can’t establish a VPN connection. Many customers don't experience issues because they have reset and regenerated certificates within that time frame, likely because they had installed and migrated to new server installations. However, if you are using an existing PKI structure that expires, you would need to reset your PKI and reprovision all of your current VPN clients, which is highly inconvenient. On Access Server, because it is possible to set up a new CA alongside the old one, a CA that is about to expire can still function while newer connection profiles are using the new CA. This allows a graceful transition from an old CA to a new one.
Access Server PKI
Access Server manages its own public key infrastructure (PKI). Here’s a high-level overview of the certificates that are involved and their purposes:
| Certificate Authority (CA) | The root certificate of the PKI. Server certificates and client certificates are signed with this. Clients receive a copy of the public part of the CA certificate to verify the validity of the server certificate. The server in turn verifies the validity of the client certificates. |
| Server key pair | What provides the proof of identity for the server, and what the OpenVPN daemon runs on. The private key and public key stay on the server, and the server sends the public key to clients for identity purposes. |
| Client key pair | A private key and public key generated for each new user account. The client has a copy of its private key, and the public key that is in the connection profile. The public key is sent to the server for identity purposes. |
| Diffie Hellman parameters | A cryptographic key used to establish a shared secret between two parties that can be used for encryption. This is part of the handshake process for setting up a secure encryption key between server and client. |
| TLS auth HMAC key | TLS authentication managed by OpenVPN that works like a software firewall. Inbound and outbound packets must be signed with this shared key, which is known by servers and clients. Packets not signed by this key are dropped. |
| TLS Crypt key | TLS crypt works like TLS authentication but adds on top of that encryption of the control channel. With TLS crypt v2, each client has its own key for this encryption instead of one shared key for all. |
| Session token HMAC key | HMAC key session tokens used to validate clients connecting to a cluster. All servers that share the same HMAC key can accept a session token generated by another server with that same key. A client that has authenticated with one server can reestablish a new session automatically with any other server in the cluster. |
Solving the CA certificate expiration problem
This diagram shows the problem that exists with CA expirations. In this example, an Access Server was installed in 2015 and therefore the certificate expires in 2025. Each user downloads a profile with an expiration date that is ten years out. User C may still have a certificate with a valid date in 2025, but can’t connect because the server’s expiration date has passed. With certificates, both the server and client certificates must be valid. This issue is only present in previous versions of Access Server, where only one CA was generated and used.
Generating new CA certificates
This diagram shows the new functionality in CA Management. Access Server version 2.9 automatically renews the CA certificate when it starts up and sees that the main CA certificate in use is older than a year. In this example, the Access Server was installed in 2015 and User A connected in that same year. Both of the certificates are valid until 2025. In 2018, the Access Server issued a new certificate using the CA Management feature in the Admin Web UI. User B connected that same year. Both of those certificates are valid until 2025 and User A can continue to connect with their certificate #1. In 2019, User A downloads a new profile, which is generated from certificate #2 and has its own ten-year expiration. This visual helps to show how the server and client certificates can be reissued to avoid disconnection issues because of expiration dates. Basically, the timer resets.
When creating a CA certificate, it consists of a private and public key with an expiration date. In Access Server version 2.9 and above, generating a new CA is done automatically. It can also be triggered manually. Whenever a client downloads a new client profile, it will get the newest CA certificate. For the client, the certificate is good for ten years. If you have a client with a certificate that goes past the ten year limit, the client must obtain a new copy of the connection profile to be able to connect. To support this, we have updated how client certificates are generated. Access Server can now handle the generation of multiple certificates per user account.
Another benefit of the new CA certificate management feature is that it provides a way for you to easily move your server and clients over from ns-cert-type to remote-cert-tls. Ns-cert-type is the Netscape model of verification of server identity using certificate properties, which is now deprecated. On Access Server version 2.4 and higher, this message displays in the log: “WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead”. The new model uses remote-cert-tls functionality, which uses the certificate Extended/Enhanced Key Usage (EKU) properties—a more modern method of defining object identifiers for using public keys. Note that Access Server continues to support older versions of clients using ns-cert.