为每台设备签发一张证书，并不等于把密钥绑定到设备
按设备签发证书是管理选择，不是设备绑定。决定绑定的是私钥存放在哪里：从可复制的文件到 TPM。
你为每台笔记本单独签发证书，于是以为 VPN 能分辨它们。它做不到。客户端证书证明的是连接方持有与证书匹配的私钥，而被复制的配置文件同样持有它。
按设备签发证书仍然是个好主意。它只是做着大多数人意料之外的另一件事。
客户端证书究竟证明了什么
握手过程中，客户端用与其证书匹配的私钥签名，服务器则用它所信任的 CA 验证该签名。这次交换里没有任何信息描述机器本身。任何同时持有证书和私钥的设备都会产生完全相同的签名，因此复制到第二台笔记本的配置文件看起来与原版一模一样。证书命名的是身份，不是硬件。
按设备保持唯一性仍然有价值，因为它让吊销变得精确。这属于管理属性，不是技术锁。
密钥存储的三个层级
第一层是磁盘上的密钥文件。它按设计就是可移植的，多数 OpenVPN 配置文件就放在那里。
第二层是操作系统标记为不可导出的密钥。Windows 可以在其证书存储中生成设备密钥并拒绝常规导出，这能阻止随手复制。它并非硬件支撑，只要对机器有足够访问权限，这类密钥仍可被恢复，所以它提高的是门槛，而不是筑起一道墙。
第三层是在安全硬件内部生成的密钥：TPM、智能卡、SIM 或 PIV 令牌。这些模块没有导出其生成密钥的电路，签名也在模块内部完成。密钥永远不会变成一个可被复制走的文件。
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
那张表就是全部论证，三行说完。
easy-rsa 能做什么、不能做什么
按设备签发证书很直接。针对同一个 CA 为每台设备创建一个不同的通用名称，例如 ./easyrsa build-client-full laptop-a nopass，然后对每台设备重复。记录哪个通用名称属于哪个人、哪台机器。
吊销同样直接：./easyrsa revoke laptop-a，用 ./easyrsa gen-crl 重新生成 CRL，并确保服务器确实通过 crl-verify 读取它。
CA 做不到的是验证私钥此后存放在哪里。如果你在 CA 主机上生成密钥再复制到设备，签发那一刻就已经造出第二份副本。不可导出的密钥必须在设备上生成，或者导入到不会把它交出去的硬件里。
在配置文件被复制之后仍然成立的控制
假设配置文件会被复制，并据此设计。为账号绑定第二因素，使单凭证书不够。给每台设备各自的策略，让一个身份的可及范围保持有限。还要留意同一个通用名称同时从两个地址连接，这正是共享配置文件在连接日志里的样子。
快速且有记录的吊销，是在复制已经发生之后仍然有效的控制。其余一切都属于预防。
服务器真正能够依赖的结论
唯一性来自 CA。设备绑定来自密钥存储。只有无法导出密钥的硬件，才能把每台设备一张证书变成服务器强制执行的结论，而不是一份人人点头的约定。