AWS Client VPN: Which CA Should Issue Client Certificates?
An existing CA, a self-run issuer and AWS Private CA split the work differently. Decide who approves, renews and revokes client certificates before launch.
The certificate question on AWS Client VPN gets asked as a product question, and it is really an operations question. Any of the three usual setups will terminate a working tunnel: an existing organizational CA, a dedicated self-run issuer, or AWS Private CA. They differ in who approves a device, who holds the signing key, and who answers when a laptop goes missing at an awkward hour. Pick the option whose owner you can name.
AWS does not require Private CA for certificate authentication. Placing a server certificate in ACM is a deployment step, not an enrollment process.
The three conditions that decide it
Three conditions separate the options cleanly: whether an approved device-enrollment process already exists, whether you can run a signing key with backups and a named owner, and how a revocation reaches the endpoint. Each is close to a yes or no, and the first no usually settles the architecture.
Work them in order. Jumping straight to a cost comparison is how teams end up with a managed CA and nobody who knows who issues the next laptop certificate.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
Condition one: does enrollment already exist?
If your organization already runs a CA with an approved device-enrollment path, issuing Client VPN client certificates from it is the shortest route. The approvals, the process and the asset records are already there. A dedicated subordinate issuer under that hierarchy is usually better than the general-purpose issuing CA, because it gives the VPN its own trust boundary and its own revocation list. Keep that list separate from the rest of the hierarchy so a VPN incident does not force a PKI-wide change.
If no such process exists, the real question is whether you want to build one. A CA is easy to start and expensive to own badly.
Condition two: can you operate a signing key?
A self-run issuer works with the documented import model, and EasyRSA or a small internal tool can produce the material. Running the command is not the hard part. The hard part is offline backups of the signing key, a recovery path someone has actually tested, an owner who is not on holiday, and a rule that the key never lands in a client bundle or a configuration export. Write that down as a procedure before the first certificate is issued, not after the first incident.
AWS Private CA moves that custody into a managed service. It does not move the enrollment policy, the approval step, or the delivery of the certificate to the device.
Condition three: how does revocation arrive?
Client VPN consumes a client-certificate revocation list that you import into the endpoint, as described in the certificate lifecycle guide. Publishing a CRL elsewhere in your PKI does not push it into the service. The import is a separate, scheduled operation, and an expired list stops connections rather than degrading quietly. Put the refresh on the same calendar as the certificates themselves.
That makes refresh a monitoring item with an owner, not a task you finish at launch. Revoke one test certificate end to end before you need the mechanism for real.
What none of the options removes
Every option still needs one distinct client certificate and key per independently managed device. A tutorial that ships a single identity to everyone is a tutorial shortcut, and it also makes selective revocation impossible.
Imported server certificates in ACM have no managed renewal, so the owner must obtain the replacement, reimport it, and then confirm the endpoint adopted it. Renewing the server certificate does not renew the client credentials already sitting on laptops. Those are separate lifecycles with separate calendars.
Check the key types and extensions the service accepts before you issue anything. A CA that supports an algorithm does not mean the endpoint will accept it.
Before launch, run one renewal and one client removal through the workflow you chose, and write down which credential changed, which endpoint setting changed, and what happened to the active session. If that exercise ends without a clear owner, the issuer choice is not finished.