AWS Client VPN：客户端证书该由哪个 CA 签发？
现有 CA、自建签发者和 AWS Private CA 的分工各不相同。上线前先确定由谁批准、续期和吊销客户端证书。
AWS Client VPN 上的证书问题常被当成产品问题来问，实际上这是运维问题。三种常见方案都能让隧道正常工作：现有组织 CA、专门自建的签发者，或者 AWS Private CA。它们的区别在于谁批准设备、谁保管签名密钥，以及在尴尬的时刻笔记本丢失时由谁出面。请选择你能说出负责人的那个方案。
AWS 并不要求证书认证必须使用 Private CA。把服务器证书放进 ACM 只是部署步骤，不是注册流程。
决定取舍的三个条件
三个条件可以清楚地分开这些方案：是否已有经批准的设备注册流程；你能否运行带备份和指定负责人的签名密钥；以及吊销如何到达端点。每一条都近似于“是”或“否”，而第一个“否”通常就决定了架构。
请按顺序处理。直接跳去做成本对比，正是团队最后留下一个托管 CA，却没人知道下一台笔记本的证书由谁签发的典型原因。
| 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 |
条件一：注册流程是否已经存在？
如果组织已经有带批准路径的设备注册 CA，从它签发 Client VPN 客户端证书是最短路径。审批、流程和资产记录都已就位。在该层级下另设一个专用的下级签发者，通常比通用签发 CA 更好，因为它给 VPN 独立的信任边界和独立的吊销列表。把这份列表与该层级的其余部分分开，这样一次 VPN 事故不会迫使整个 PKI 变更。
如果不存在这样的流程，真正的问题是你是否想建一个。CA 起步容易，管理不善则代价高昂。
条件二：你能否运行签名密钥？
自建签发者可以使用文档化的导入模型，EasyRSA 或小型内部工具就能生成所需材料。执行命令并不是难点。难点在于签名密钥的离线备份、有人真正测试过的恢复路径、不休假的负责人，以及密钥绝不进入客户端包或配置导出的规则。请在签发第一张证书之前把它写成流程，而不是在第一次事故之后。
AWS Private CA 把这种保管转移到托管服务，但不会转移注册策略、审批步骤，也不会把证书送到设备上。
条件三：吊销如何送达？
Client VPN 使用的客户端证书吊销列表需要你导入端点，正如证书生命周期指南所述。在你的 PKI 其他地方发布 CRL 并不会把它推进服务。导入是独立的定时操作，而过期的列表会直接中断连接，而不是悄悄降级。请把续期放在与证书本身相同的日历上。
这使续期成为有负责人的监控项，而不是上线时就结束的任务。在真正需要这套机制之前，先把一张测试证书完整吊销一遍。
任何方案都无法消除的事
每种方案仍然需要每台独立管理的设备各有一张客户端证书和一把密钥。给所有人发同一身份的教程是教程式的捷径，也让选择性吊销变得不可能。
导入 ACM 的服务器证书没有托管续期，因此负责人必须取得替代证书、重新导入，然后确认端点已采用它。续期服务器证书并不会续期笔记本上已有的客户端凭据。它们是各自日历上的独立生命周期。
签发任何东西之前，先确认服务接受的密钥类型和扩展。CA 支持某种算法，并不意味着端点会接受它。
上线前，用你选定的工作流跑一次续期和一次客户端移除，并记录哪项凭据变了、哪个端点设置变了，以及活动会话发生了什么。如果这次演练结束时没有明确负责人，签发者的选择就还没有完成。