通过 SSL/TLS 进行身份验证

概览

传输层安全 (TLS) 曾经也被称为安全套接层 (SSL)，是一种安全协议，它为在客户端和服务器之间交换的消息确保机密性和完整性，在最典型的用例中，会由客户端对服务器进行身份验证。

相互 TLS 身份验证 (mTLS) 也称为客户端证书身份验证 (CCA)，可在 TLS 握手过程中增加客户端身份验证。这种验证方式与客户端验证服务器的方式非常相似，也会用到在握手期间交换的 X509 证书。一旦握手完成，即会对经过身份验证的身份进行校验，以确保其具有发出请求的授权，这种方式与使用基于 HTTP 的身份验证机制相同。

要想使用 mTLS，您必须首先安全地向我们发送一个或多个与您的账户关联的发卡机构证书。然后，您可以通过要发送的客户端证书及其对应的私钥，来对您的客户端进行配置。该证书必须由您已发给我们的发卡机构证书之一签署（或者，您也可以使用发卡机构证书签署的中间证书）。

在 TLS 握手期间，我们的服务会请求您提供一个证书。您的客户端会向我们发送证书以及拥有私钥的证明。您可以选择在握手包含一个中间证书。然后，我们会根据五项标准来验证您的身份：

1. 我们服务器上的时间必须在客户端、可选中间证书和发卡机构证书的有效期内。
2. 每个证书的签名必须有效，而信任链可利用您先前提供给我们的发卡机构证书之一来终止。
3. 拥有客户端证书的相应私钥的证明必须有效。
4. 我们没有信任链中任何证书的撤销通知。
5. 如果您已经为客户端证书的可分辨名称提供了任何 RDN，那么它们大部分就能匹配。

集成指南

执行以下步骤以设置进出 Access Worldpay 的所有流量的 mTLS。

第 1 步 - 覆盖 Access Worldpay 主机名称的 IP 地址

您的本地配置必须覆盖 try.access.worldpay.com 和 access.worldpay.com 的 IP 地址。其目的是将您的流量通过 mTLS 安全接入点指向我们的服务。在不更改 IP 的情况下，TLS 握手成功，但由于您没有提供身份或身份验证数据，您的请求失败。

每个环境都有两个 IP 地址以实现故障隔离设计，从而通过 mTLS 提高 Access Worldpay 的可用性。这两个 IP 由两组不同的物理基础设施托管和管理。如果一个 IP 不可用，则另一个将投入使用。

第 2 步 - 提供发卡机构证书

您必须提供一个或多个发卡机构证书（通过商定的安全通道）。我们将用其来验证您发送给我们的客户端证书。

这必须是一个安全通道，以便我们知道发卡机构证书来自于您，而并非恶意第三方。

您可以对 Try 和 Live 使用相同的发卡机构证书，但我们建议您不要这样做。

第 3 步 - 提供客户端证书 DN 验证标准（可选）

提供零个或多个证书相对可分辨名称 (RDN) 类型/值对，以便在接收到客户端证书时与之匹配。

例如，您可以指定：

C=UK
O=AwesomeMerchant

我们将检查 DN 的每个 RDN，而且只要符合所有的标准，这可能就会被接受。

已被接受的 DN 值的示例：

• CN=client1,O=AwesomeMerchant,C=UK - （可以添加 CN）
• CN=client1,C=UK,O=AwesomeMerchant - （顺序不重要）
• CN=client1,O=AwesomeMerchant,L=Cambridge,C=UK - （可以添加任何其他 RDN）

已被拒绝的 DN 值的示例：

• CN=client1,O=AwesomeMerchant （缺失 C=UK）
• CN=client1,O=AwesomeMerchants,C=UK （不匹配的 O RDN）

如果您不提供任何标准，则我们接受与您账户相关的发卡机构签署的任何有效证书。

管理您的证书

更新发卡机构证书

当发卡机构证书即将到期时，您必须向我们发送新的发卡机构证书。然后，只要证书尚未过期，我们就可以接受由任何发卡机构签名的客户端证书。如果信任链中的任何证书过期或由于其他原因而无效，则 TLS 握手失败。

一旦发卡机构证书过期，它就会在我们这一侧被自动删除。您无需明确提出删除请求。

撤销证书

如果您希望撤销某个证书，例如由于对应的私钥遭到破解，则可以使用手动或自动化流程。

自动化：对于您提供的所有客户端证书、中间证书和根证书，我们至少每 24 小时校验一次证书中指定的在线证书状态协议 (OCSP) URL。如果超过连续 7 天无法联系到您的 OCSP 端点，我们将通知您。

手动：如果您无法提供或更新发卡机构证书的 OCSP 端点，那么您可以通过商定的安全通道与我们联系，并向我们提供要撤销的证书身份。然后，我们会从您的账户中删除特定的证书。我们不会为此方法保留无效证书的列表。

不支持证书撤销列表 (CRL)。

约束条件/规则

客户端证书必须是 X509v3 版本，并符合以下约束条件：

• 所有证书必须使用 RSA、DSA 或 ECDSA 证书签名算法。
• 所有证书必须使用 SHA-2 加密哈希算法进行签名。
• 您可以在每个请求上提供一个中间证书和客户端证书。
• 您提供的发卡机构证书必须包含 CA 基本约束条件和 Certificate Sign 密钥使用扩展。
• 您提供的客户端证书必须包含 TLS Client Authentication 密钥使用扩展。
• 客户端证书必须包含非零长度的可分辨名称 (DN) 组件。所有子组件（CN、O、OU、C 等）均为可选。您可以添加自己的自定义子组件。
• 提供给我们的发卡机构证书必须由您的组织控制，以确保恶意第三方无法创建可能被我们接受的客户端证书。
• OCSP URL 可以使用授权信息访问 (AIA) 扩展在证书中提供。

如果任何这些限制条件未得到满足，则 TLS 握手不成功，因此您无法向 Access Worldpay 服务提交请求。

其他技术信息

与 HTTP 身份认证共同使用

您不应在 HTTP Authorization 头文件中提供任何值。即使提供，所有值都会被忽略。

TLS 版本

必须只能使用 TLS v1.2 或 TLS v1.3.

TLS v1.3 注释

支持以下密码套件：

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256

由于存在转发保密和重放攻击风险，我们不支持 0-RTT。

TLS v1.2 注释

对于 TLS v1.2，只支持带附加数据的身份验证加密 (AEAD) 套件。

您可以在初始握手后使用重新协商流来提供您的客户端证书。但请注意，这样会对性能造成影响，因为重新协商流需要在您的客户端和我们的服务之间进行更多次的往返。

支持以下密码套件：

• TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
• TLS_ECDHE_ECDSA_WITH_AES128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_CHACHA20-POLY1305

我们将限制在这些密码套件中的实施，原因如下：

1. 它们提供转发保密，i.e.，所有连接都使用了临时密钥，而不是使用证书中的密钥进行保护。
2. AEAD 密码模式（特别是 GCM）可以规避 CBC 等密码模式的漏洞。
3. SHA-2 加密哈希函数没有实际的漏洞，不像 SHA-1 和 MD5 存在现实世界中可利用的漏洞。

mTLS 的优缺点

对您和我们来说，mTLS 是客户端验证自己身份的一种更安全的方式。但它还是要付出代价的。以下是 mTLS 的一些优缺点。

凭证是私密的

客户端证书由您创建和管理。证书中包含的与公钥对应的私钥永远不会与 Worldpay 共享。即使私钥遭到破解，这样就能为您提供更强的机密控制能力和对 Worldpay 的不可否认性。

内置凭证到期

我们不强制规定客户端凭证的过期日期，因此您能以最适合自己安全标准和政策的方式来管理客户端证书。

客户端自主管理

您可以按照自己选择的方式来随意管理客户端证书：在任何适当的时候添加新证书、撤销现有证书或替换证书。我们不需要收到相关通知，但前提条件是您不得更改发卡机构证书。

复杂性

管理证书的公钥基础设施 (PKI) 需要仔细设计、投资和持续维护，以保障可接受的安全级别。这也特别适用于您必须托管一个可靠的 OCSP 端点的情况。

证书过期风险

如果证书过期，则您的 TLS 握手不成功，因此您的请求不会被处理。这意味着在您替换客户端或发卡机构证书之前，您无法在我们的平台上处理支付。

因此，您必须密切关注证书过期日期。

设置 mTLS

设置密钥和证书可能会成为一项艰巨的任务，以至于 PKI 通常都要由专职安全团队管理。如果您想在开发和 QA 环境中快速开始使用 mTLS，我们已经创建了为 Try 设置 mTLS，它会为您详细介绍如何使用无处不在的OpenSSL工具包来创建所需的工件。