为了更容易区分客户端证书，你可以生成你自己的私钥和 CSR，并输入将包含在你的证书请求中的信息，本质上是对你的客户端证书进行标记。
在注意到异常流量、不正常流量（奇特序列的请求）或注册了来自使用你客户端证书的特定设备的大量攻击尝试的情况下，最好吊销这些证书。
此外，确保配置了 WAF 自定义规则以封禁已吊销的客户端证书。审查可用的 cf.tls_* 字段。
带有操作块的 WAF 自定义规则示例：
(cf.tls_client_auth.cert_revoked)更好的方法可能是检查未验证或已吊销的客户端证书：
(not cf.tls_client_auth.cert_verified) or cf.tls_client_auth.cert_revoked通常，请确保定期且安全地轮换客户端证书，以降低泄露风险。
有多种方式可以将客户端证书转发到你的源站服务器。
如果你已经实现了 mTLS，且客户端证书已安装在设备上，因此你希望使用自己的证书颁发机构 (CA)，这可以通过为 mTLS 使用你自己的 CA 来实现。
你可以通过仪表板或替换主机名关联 API 端点将你上传的 CA 与特定主机名相关联。
有不同的方式可以在设备之间安全地部署客户端证书。
一些最常用的方法包括：将客户端证书嵌入到应用程序中并允许用户设备下载并安装该 App；或者使用移动设备管理 (MDM) 在设备之间分发证书；或者允许用户设备直接下载并安装客户端证书到设备的证书存储库中。
签发证书是一个重要步骤，因此如果可能，请执行彻底的客户端验证。
在复杂的微服务环境中，你可以利用 Service Mesh 大规模自动化和强制执行 mTLS。例如，Cloudflare 服务可以处理外部流量安全，而 Service Mesh 技术可在你的网络内部对东西向流量强制执行 mTLS。这可确保外部流量由 Cloudflare 保护，而内部微服务通信通过 Service Mesh 使用 mTLS 受到保护。
通常建议自定义 Cloudflare Edge 证书的加密套件。这仅适用于 Edge 证书，不适用于客户端证书。
推荐用于 mTLS 的 TLS 版本为：
- TLS 1.2：依然广泛兼容且安全。
- TLS 1.3：因其增强的防范安全性和效率，成为新实现的优选。
由于已知的漏洞，不建议使用像 TLS 1.0 或 1.1 这样过时的版本。
如果浏览器连接到配置了 通配符 Edge 证书 的域名，并且连接到该域名的 mTLS 子域名，则由于 TLS 会话复用（也称为 连接复用/0-RTT Connection Resumption），可能会引发非身份验证事件。
通常不建议使用通配符证书。
有关更多信息，请参阅故障排除文档。
如果你需要在 TLS 握手之后通过重新协商使用客户端证书，你需要使用低于 1.3 的 TLS 版本。这是因为 TLS 1.3 不支持重新协商。
例如，如果你正在使用 mTLS，并且根据请求中的 URL 路径限制对某些文件夹的请求，而不是限制源站服务器上的所有内容，则可能会触发 TLS 重新协商。使用 TLS 1.3 的连接不支持重新协商。
客户创建客户端证书并选择 使用我的私钥和 CSR 选项。客户提供由最终客户提供的 CSR，以生成与最终客户共享的客户端证书。但是，如果你的最终客户请求证书链，该证书链可能可以通过 Cloudflare 账户团队提供。
联系你的账户团队获取更多信息。
为了有效地与 Cloudflare 一起实现 mTLS，强烈建议适当配置 Cloudflare WAF。审查可用的 cf.tls_* 字段。
带有操作块的 WAF 自定义规则示例：
(http.host in {"mtls.example.com" "mtls2.example.com"} and (not cf.tls_client_auth.cert_verified or cf.tls_client_auth.cert_revoked))此表达式将检查请求是否来自主机名之一，如果客户端证书未验证或已吊销，则会封禁请求。
另一个带有操作块的 WAF 自定义规则示例，使用 cf.tls_client_auth.cert_fingerprint_sha256 字段针对特定客户端证书（替换 ADD_STRING_OF_CLIENT_CERT_SHA256_FINGERPRINT）：
(http.request.uri.path in {"/headers"} and http.host in {"mtls.example.com" "mtls2.example.com"} and not cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_fingerprint_sha256 ne "ADD_STRING_OF_CLIENT_CERT_SHA256_FINGERPRINT")这里是另一个将序列号与主机名关联的 WAF 自定义规则示例：
(http.host in {"mtls.example.com" "mtls2.example.com"} and cf.tls_client_auth.cert_serial ne "ADD_STRING_OF_CLIENT_CERT_SERIAL")此表达式将检查链接到特定主机名的特定客户端证书序列号，从而实现更精细的控制。
通过 Cloudflare API 启用转发证书后，mTLS 连接的每个请求都将包含以下请求头：
Cf-Client-Cert-Der-Base64（DER 格式的原始证书，以 base64 编码）Cf-Client-Cert-Sha256（证书的 SHA256 指纹）
请求头 Cf-Client-Cert-Sha256 可以在速率限制特征的“请求头的值”中使用。
速率限制规则示例：
(http.host in {"mtls.example.com" "mtls2.example.com"} and cf.tls_client_auth.cert_verified)
具有相同的特征...
"请求头的值": "Cf-Client-Cert-Sha256"除了 mTLS 之外，客户还可以购买 API Shield 功能，例如 API Discovery、API Routing、Volumetric Abuse Detection、Sequence Mitigation、JWT Validation、Schema Validation 等。
Cloudflare Workers 可以提供围绕客户端证书的详细信息，例如通过请求头向客户端或源站服务器返回信息。在下方的 在 Workers 中使用 mTLS 部分 中了解更多信息。