Migrating To A New CA For OpenVPN

Attention OpenVPN administrators! We know that from time to time, for security or other related reasons, it becomes necessary to replace the Certificate Authority (CA) of an OpenVPN installation. For small installations, if all clients and servers can be updated in a very short period of time and downtime is not an issue, then there is a simple solution: each client and server receive new keys and certificates.

But, what happens if you need to experience an installation without any downtime? Maybe you're in different time zones or on hundreds of different devices that may not even be online at all times. Now this is a different story.

Read below to learn how you can completely replace the CA used for a VPN network with zero downtime.

Initial Situation

All client and server certificates have been signed into the old CA.

The CA and all certificates should get replaced by new ones. Downtimes should be prevented, except for short server restarts.

It's impossible to update all clients at the same time. The VPN server needs a way to support both old and new client certificates for the time of the migration.

Simple Migration - Step 1 - Update Server CA Certificate

In the first step, the root certificate of the new CA gets added to the CA file of the OpenVPN Server (stacked certificate).

Simple Migration - Step 2 - Update Certificates on Clients

The clients are updated consecutively. Each client gets a new client certificate, together with a new private key, as well as the root certificate of the new CA.

Because the server already holds the root certificate of the new CA in its CA file, along with the old one, it is able to verify both old and new client certificates.

ALL clients need to be updated prior to continuing on to the next step.

Simple Migration - Step 3 - Update Server Certificate

Once ALL clients have been updated accordingly, the server certificate gets replaced by a new one, signed by the new CA.

The clients are able to verify the new server certificate using the root certificate of the new CA that they have previously received.

Simple Migration - Step 4 - Cleanup on Server and Clients

Finally, the old CA certificate should get removed from the server and from all clients.

Unfortunately, this requires a further update on all VPN clients.

There are two major disadvantages to this migration process:

• The server certificate can only get replaced once ALL clients have been updated on the new root CA.
• It requires two updates to each VPN client. This can take quite some effort with hundreds or thousands of clients and devices.

Fortunately, we found a new way that shares none of the above mentioned disadvantages.

Improved Migration - Step 1 - Update Server Certificates

In the first step, the root certificate of the new CA gets added to the CA file of the OpenVPN Server (stacked certificate).

Also, the server certificate is replaced by one signed by the new CA. Additionally, an intermediate certificate (OLD-NEW-IM.crt) that uses the private key of the new CA, but is signed by the old CA, gets added to the server certificate file.

So, the server certificate file will consist of both the actual new server certificate, and the intermediate certificate. The VPN server will return both certificates to each connecting client.

This allows clients that only support the root certificate of the old CA to verify the intermediate certificate, which in turn verifies the new server certificate.

IMPORTANT: When signing the new server certificate, the 'authorityKeyIdentifier' section must only include the keyid, and not the issuer. This is neccessary to prevent issues related to different subjects of the old and new CA's.

Furthermore, the expiration date of the intermediate certificate should be set to the deadline of the migration. Once it expires, clients that still have the old CA certificate only will be unable to connect.

Improved Migration - Step 2 - Update Certificates on Clients

The clients are updated consecutively. Each client gets a new client certificate, together with a new private key, as well as the root certificate of the new CA.

The root certificate of the old CA gets removed from the updated clients immediately.

Using the new root certificate, the updated clients are able to verify the new server certificate without using the intermediate certificate.

Because the server already holds the root certificate of the new CA in its CA file, along with the old one, it is able to verify both old and new client certificates.

ALL clients need to be updated prior to continuing to the the next step.

Improved Migration - Step 3 - Cleanup on Server

Finally, the old CA certificate and the intermediate certificate should get removed from the server.

There are three advantages to this migration process:

• It is possible to deploy the new server certificate in the first step. This is especially helpful if some VPN client software requires specific CA properties that are not met by the old CA. By following this migration path it's possible to support new software right away without waiting for all old clients to get updated first.
• Each VPN client needs to get updated only once.
• It is possible to set a deadline for the migration by adjusting the expiration date of the intermediate certificate. And in a worst-case-scenario, it would still be possible to create a new intermediate certificate.

We hope this blog post proves useful for our partners and customers!

Best,

Jens Wagner, head HEXOnerd and HEXONET CEO

For more tips and tricks on all things domains, online security, technology and more, from Jens Wagner and the rest of the executive team, visit hexonet.net, or follow our blog.