Introduction
In the Access Server version 2.9 release, we added support for multiple CA certificates. This documentation details managing your VPN server's certificates and user profiles. Also, we 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.
For further information, refer to the user manual: Configuration: CA Management.
For advanced options from the command-line interface, refer to Advanced CA Certificate Management (CLI).
Managing user profiles
You’ll see a new User Profiles section in the Admin Web UI and the new CA Management page. While previous Access Server versions had a page to revoke certificates, we replaced this with the User Profiles section because your users can now have multiple profiles.
You can add, download, or delete user profiles from the User Profiles page and view information such as the signing CA and the expiration date. For further information, refer to the user manual: User Management: User Profiles.
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 crucial to defend against man-in-the-middle attacks, where an attacker sitting between the VPN client and the VPN server can attempt to redirect or capture the traffic or dupe the user into divulging server credentials.
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 specific timeframe; by default, this has been set to 10 years from the date you installed Access Server, although this is configurable.
Access Server 2.9 and newer includes two key features unavailable in previous versions:
- Automatic CA renewal each year.
- Manual CA generation with the cross-signing of the old CA.
Manual CA certificate generation with cross-signing of the old CA allows your server to accept connections from old and new certificates. 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. Access Server 2.9 installations used 2048-bit RSA certificates. We recommend using the secp384r1 algorithm, which is the default as of Access Server 2.12.0.
Updating from RSA certificates to secp384r1 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 the latest version of Access Server, you can set up a new CA alongside the old one and accept connections from both. This allows a graceful transition.
CA certificates expire after ten years on older versions of Access Server. 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 current VPN clients, which is highly inconvenient. On the latest AS versions, you can set up a new CA alongside the old one, which means a CA about to expire can still function while newer connection profiles use 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 server certificate's validity. The server, in turn, verifies the validity of client certificates. |
| Server key pair | What provides the server's proof of identity 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 | Private and public keys generated for each new user account. The client has a copy of its private key and the public key 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, 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 authenticated with one server can re-establish 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; therefore, the certificate expires in 2025. Each user downloads a profile with an expiration date 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 need to be valid. This issue is only present in previous versions of Access Server, where only 1 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 primary CA certificate now in use is older than a year. In this example, the Access Server was installed in 2015, and User A connected that same year. Both of the certificates are valid until 2025. In 2018, Access Server issued a new certificate using the CA Management feature in the Admin Web UI. User B connected that same year. Both certificates are valid until 2025, and User A can continue to connect with certificate #1. In 2019, User A downloads a new profile generated from certificate #2, with its 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. Access Server 2.9 and newer generates a new CA automatically. You can also generate one manually. A client gets the latest CA certificate whenever they download a new client profile. 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 connect. To support this, we updated client certificate generation. 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 allows you to move your server and clients from ns-cert-type to remote-cert-tls easily. 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.