AWS Client VPN：服务器证书与客户端证书的角色分工
终端节点的服务器证书用于证明服务身份。双向认证在不共享服务器密钥的前提下，增加每客户端身份与 CA 信任。
Client VPN 终端节点始终需要一张 TLS 服务器证书。那是受管终端节点在客户端连接时出示的身份。它与启用双向认证时各个客户端出示的证书是两回事。把两者混为一谈，正是一套本来正确的 ACM 配置仍在首次连接时失败的最常见原因。
下面按连接实际经过的顺序，从控制台由内向外走一遍。
两种角色，一个终端节点
终端节点拥有服务器身份，并可选地拥有验证客户端身份的手段。这两者分开配置。一个决定 客户端能否信任该服务，另一个决定服务是否接受该客户端。
| Material | Purpose | Where it lives |
|---|---|---|
| Server certificate and private key | The managed endpoint proves its TLS identity | ACM, in the endpoint's Region |
| Client certificate and matching key | An individual client proves its identity | On the device |
| CA trust material | The verifier checks the issuer chain | Selected for the client role |
请把表格读成三项彼此独立的要求，而不是一张证书。服务器证书及其私钥留在服务侧。客户端证书及配对的私钥保存在设备上。CA 材料才是验证方用来检查证书链的东西。只有中间那一行才属于笔记本电脑。
ACM 服务器证书的作用
创建终端节点时，服务器证书必须位于与终端节点同一区域的 ACM 中。控制台要求填写 ARN，而该 ARN 必须能在那里解析。ACM 可以存放通过域名验证签发的证书，也可以存放连同私钥和证书链一起导入的证书。两者都能胜任这个角色；差别在于续期方式以及私钥由谁保管。
请按谁能够续期证书来选择签发路径，而不是按哪条路径恰好生成了一个看起来有效的文件。
双向认证额外增加的内容
选择基于证书的客户端认证，会多出第二个问题：究竟哪些客户端可以连接。每个客户端出示自己的证书，并证明自己持有配对的私钥。正是彼此独立的身份，才让日后的选择性吊销成为可能。把同一把客户端密钥复制到每台设备上，就等于悄悄丢掉了这一特性，即使服务器证书取得得完美无缺。
终端节点的认证方式是一种选择，而不是普遍要求。
Active Directory 与联合身份认证用别的手段回答同一个问题。双向证书方案并不自动成为这些部署的登录设计，而且无论用户以何种方式被放行，服务器端的 TLS 验证始终保留。
为什么同一个 CA ARN 不等于共享密钥
AWS 的文档指出，当服务器证书与客户端证书由同一个 CA 签发时，服务器证书的 ARN 也可以用于选择客户端证书。那句话讲的是验证时终端节点信任哪条链，并没有让客户端去使用服务器的私钥。笔记本电脑仍然需要自己的客户端证书和自己的配对密钥。
当客户端 CA 来自另一个签发者时，文档给出的路径是把该 CA 导入 ACM，并为客户端角色选中它。
把故障回溯到某个阶段
在更换任何东西之前，先判断是哪一阶段失败。如果客户端拒绝终端节点，可疑的是服务器 ARN 或其证书链。如果终端节点拒绝客户端，就去看客户端证书、它的签发者以及所选的认证方式。如果隧道已经建立而流量仍然失败，那问题早已不在证书上。
一次只换一个对象，因为同时更换两端只会把你最初面对的那份含糊重新造出来。
还要检查该角色所支持的密钥算法与必需的扩展项。一张能满足公开网站的证书，并不证明 Client VPN 的全部身份要求都已满足。
写下每个字段各持哪个 ARN、是哪家 CA 签发了客户端证书、终端节点实际使用哪种认证方式。三行记录就能让下一次续期变成一项任务，而不是一场排查。