Why Re-importing a Client VPN Certificate Needs a New Endpoint

A Client VPN connection breaks, the certificate in ACM gets replaced, and nothing changes. The certificate object was never the thing the endpoint was using. An endpoint stores an association to a certificate at creation time, along with the client CA it will validate against, the authentication type, the subnets and the authorization rules, and none of those associations has a modify call that accepts a replacement certificate. Replacing the bytes behind an ARN is a change to the certificate, not to the endpoint that captured it.

The endpoint stores references, not certificates

The mechanism is worth stating precisely because it explains the whole failure. create-client-vpn-endpoint takes a server certificate ARN and a client root certificate chain ARN, and the resulting endpoint keeps those references plus the authentication options as fixed properties. The API surface offers no operation that swaps the server certificate on an existing endpoint.

You can confirm the binding without guessing. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 prints the certificate ARN, the client root chain ARN, the authentication type, the client CIDR and the associated subnets, which is the full set of properties you would have to reproduce. Run it before and after a re-import and the output does not move. That is the evidence that the re-import was never going to help.

Why a re-import cannot reach the endpoint

A re-import writes a new certificate body under an existing ARN. That is a legitimate operation when a certificate is near expiry, and ACM will accept it as long as the private key matches and the chain validates. What it does not do is re-run the endpoint's creation-time validation, so the association and the material behind it stay as they were when the endpoint was built.

This is also why the symptom reads like a network fault. The TLS handshake fails or resets before authorization is ever evaluated, so security groups, routes and authorization rules all look innocent, and they are.

The chain is part of the client certificate

The second half of the failure is in the client certificate, and it is easier to dismiss. A client certificate must be imported with the chain that issued it, even though the import form presents that field as optional. Without the chain the endpoint cannot build a path from the client certificate to the client root CA it was configured with, and the connection ends in a soft reset that reads like a firewall dropping packets. openssl verify -CAfile root-ca.pem client.crt answers that question locally in a second, and it should be the first command you run.

Re-importing with the chain is a real fix for that half, and it is still not enough on its own. Once the ACM object has changed, the endpoint holding the old association is the wrong thing to keep testing against. Both steps belong to the same repair, which is why the two-part fix is not a contradiction.

Recreating an endpoint is a migration

Creating a replacement endpoint is a migration, not a retry, and treating it as a retry is how teams end up with two half-configured endpoints. The new endpoint gets a new ID and, unless you planned for it, a new DNS name for every user. Keep the client profile pointing at a name rather than an address so the swap becomes a record change instead of a redistribution.

The order that keeps this safe is short: create the new endpoint with the same CIDR, subnets and authorization rules, export a fresh profile with aws ec2 export-client-vpn-client-configuration, and verify with one user. Only after that does the old endpoint come down.

Retiring the old endpoint has its own order. Revoke the client certificates you meant to retire before you delete it, because a new endpoint that still trusts the old CA keeps accepting certificates you believed were gone. Then delete the old endpoint and remove its authorization rules, so a stale profile cannot reconnect to a target network you thought was closed. Write the old endpoint ID and the association identifiers into the change record, because a migration compared against memory is how a working endpoint gets rebuilt twice.

Order the diagnosis

Separate three failures before changing any configuration. The client cannot complete TLS, the client completes TLS and is not authorized, or the client connects and cannot reach a destination. Certificate association belongs to the first, an authorization rule that does not cover the client address belongs to the second, and a route or security group belongs to the third, where recreating an endpoint is almost always the wrong move.

An endpoint that worked for months and then stopped, with no certificate or policy change, is its own case. Rebuilding it with identical settings may restore service, but that is a reason to keep the configuration reproducible rather than a reason to rebuild on every incident.

Keep four things in version control so the next rebuild is a diff instead of an improvisation: the endpoint parameters, the certificate and chain ARNs, the authorization rules and the client CIDR. The Client VPN authentication documentation lists which certificate plays which role, which is worth checking before assuming a certificate is the problem at all. If a re-import changes nothing and the endpoint still resets, the association is the suspect and the answer is a new endpoint built from the recorded parameters. If the endpoint does pick up the new object, the association was already correct and the fault sits in the client chain or the authorization layer.