仅因网关的证书工具默认使用 RSA 就选择 RSA,是在真正重要的问题之前做决定;那个问题是:这些 iPhone 将如何注册?用户手动输入的连接与管理方下发的配置描述文件暴露的设置并不相同,有些证书选项只存在于其中一条路径上。顺序正确,证书方案就会很短;顺序错误,就会签发一部手机根本不会使用的凭据。请把下面的步骤视为一个序列,因为每一步都在收窄下一步可用的选择。

第一步:选择注册路径

手动设置意味着用户输入服务器地址、选择认证方式,并提供界面允许的任何凭据。受管理注册意味着描述文件携带地址、标识符以及对凭据负载的引用。受管理路径能表达手动界面无法表达的组合,因此证书决策必须排在这一选择之后,而不是之前。

两条路径都能认证一部手机。它们在可配置的内容以及身份归属上有区别,所以要有意识地选择一条,而不是把受管理描述文件和手动凭据输入混在一起。

第二步:为所选路径挑选算法

对于手动配置的 iPhone,strongSwan 的 iOS 互操作说明建议使用 RSA 服务器证书,因为手动客户端可能不接受 ECDSA 服务器证书;同一份说明对 macOS 另行处理。请把这当作对受支持客户端群的指引,而不是关于 Apple 设备的永久法则。受管理描述文件的余地更大:当负载和网关两者都支持时,它可以明确选择证书类型,包括 ECDSA 客户端身份。

在部署任何东西之前,先验证你真正支持的 iOS 版本。实验室里最新版本的手机并不能描述包含旧设备的机群,而在实验室可用的算法仍可能在场内最旧的手机上失败。版本范围要从设备管理系统中取得,而不是凭记忆。如果机群跨越多个版本,先测试最旧的那一版,因为手动界面的限制在那里最严格。

第三步:把描述文件字段当作彼此独立的东西

几个名称近似的键描述的是不同对象。远程地址是手机拨号的主机。远程标识符是它期望网关出示的 IKE 身份。负载里的证书引用指向客户端凭据,而证书类型字段选择用于 IKEv2 机器认证的类型。这些都不是 CA 的签名算法,尽管字面上有重叠。

Apple 的 IKEv2 负载参考把 RSA 列为默认证书类型,并给出明确的 ECDSA 变体,同时把签发者名称键与特定认证设置绑定。请在你所选方法的参考文档里阅读这些关系,而不是从一份能用的部署里照抄某个键。

第四步:让网关身份与其证书一致

使用明确的网关名称,例如 vpn.example.com 并在服务器证书中放入 一个匹配的主题备用名称。strongSwan 的 Apple 指引还要求服务器认证的扩展密钥用法。选择 RSA 还是 ECDSA 都不改变这一点:算法无法修复名称不匹配、缺失的 EKU 或不完整的证书链。

分发信任锚是与声明身份分开的任务。手机需要一条它能验证的证书链,而且必须配置为期望你真正写入证书的那个名称。

另一个平台能成功连接,是关于那个平台验证规则的证据,并不是放宽手机规则的许可。除非你有书面理由需要不同,否则应让各类客户端的检查保持一致。

第五步:把客户端身份与 CA 信任分开

客户端证书及其私钥与手机所信任的 CA 证书不是同一个对象。把 CA 证书打包进 PKCS#12 身份,并不会自动把它安装为每台受支持设备上的信任锚,所以要把信任分发当作一个带独立验证的单独步骤。

如果设计改用基于密码的 EAP,手机就需要预期的账户认证加上服务器验证。那条路径并不能为向整个机群分发同一个共享客户端私钥提供理由,那是另一种设计,失效模式要糟得多。

收尾时把续期和吊销考虑进去:谁重新签发客户端凭据、描述文件如何更新、丢失的手机如何切断。记录描述文件版本和你验证过的设备版本,因为正是这份记录让下一次证书轮换成为例行变更。

相关文章