AWS Client VPN: Server Certificate vs Client Certificate Role

A Client VPN endpoint always needs a TLS server certificate. That is the identity the managed endpoint presents when a client connects. It is a different object from the certificates individual clients present when mutual authentication is in use. Mixing the two up is the most common reason an otherwise correct ACM setup still fails on the first connection.

Here is a walkthrough from the console outward, in the order a connection actually traverses.

Two roles, one endpoint

The endpoint owns a server identity and, optionally, a way to verify client identities. Those are configured separately. One decides whether the client can trust the service; the other decides whether the service accepts the client.

Read the table as three independent requirements rather than as one certificate. The server certificate and its private key stay with the service. A client certificate and its matching private key live on the device. The CA material is what a verifier uses to check the chain. Only the middle row ever belongs on a laptop.

What the ACM server certificate does

When you create the endpoint, the server certificate must be available in ACM in the same Region as the endpoint. The console asks for an ARN, and that ARN has to resolve there. ACM can hold a certificate you provisioned with domain validation, or one you imported together with its key and chain. Both work in this role; they differ in renewal and in who holds the private key.

Choose the provisioning path that matches who can renew the certificate, not the one that happened to produce a valid-looking file.

What mutual authentication adds

Selecting certificate-based client authentication adds a second question: which clients may connect at all. Each client presents its own certificate and proves possession of the matching private key. Separate identities are what make selective revocation possible later. Copying one client key onto every device quietly discards that property, even when the server certificate was obtained perfectly.

The endpoint's authentication method is a choice, not a universal requirement.

Active Directory and federated authentication answer the same question by other means. A mutual-certificate recipe is not automatically the login design for those deployments, and server TLS verification stays in place regardless of how the user is admitted.

Why the same CA ARN is not key sharing

AWS documents that when the server and client certificates are issued by the same CA, the server certificate ARN can also be used for the client-certificate selection. That sentence is about which chain the endpoint trusts for verification. It does not tell clients to use the server's private key. A laptop still needs its own client certificate and its own matching key.

When the client CA is a different issuer, the documented path is to import that CA into ACM and select it for the client role.

Walk the failure back to a stage

Identify which stage is failing before you replace anything. If the client rejects the endpoint, the server ARN or its chain is the suspect. If the endpoint rejects the client, look at the client certificate, its issuer and the selected authentication method. If the tunnel comes up and traffic still fails, you are past certificates entirely.

Replace one object at a time, because swapping both ends at once reproduces the ambiguity you started with.

Check the service's supported key algorithms and required extensions for the specific role as well. A certificate that satisfies a public website is not proof that every Client VPN identity requirement has been met.

Write down which ARN each field holds, which CA issued the client certificate, and which authentication method the endpoint actually uses. Three lines of record turn the next renewal into a task instead of an investigation.