4.7.2. 保护 broker-client 连接
如果您已在接收器或连接器（即，通过将 sslEnabled 设为 true）上启用了安全性，您必须配置传输层安全(TLS)以允许代理和客户端之间进行基于证书的身份验证。TLS 是更新的、更安全的 SSL 版本。有两个主要 TLS 配置：
- 单向 TLS
- 只有代理才会显示证书。该证书供客户端用于验证代理。这是最常见的配置。
- 双向 TLS
- 代理和客户端都存在证书。这有时称为 相互身份验证。
以下部分描述：
对于单向和双向 TLS，您可以通过生成一个 secret 来完成配置，该 secret 存储在代理和客户端之间成功 TLS 握手所需的凭证。这是您必须在安全接收器或连接器的 sslSecret 参数中指定的 secret 名称。secret 必须包含 Base64 编码的代理密钥存储（单向和双向 TLS）、Base64 编码的代理信任存储（仅限双向 TLS），以及这些文件的对应密码（也是 Base64 编码的）。单向和双向 TLS 配置程序演示了如何生成此机密。
如果您没有在受保护的接收器或连接器的 sslSecret 参数中明确指定 secret 名称，则接收器或连接器会假定默认 secret 名称。默认 secret 名称使用格式 <custom_resource_name>-<acceptor_name>-secret 或 <custom_resource_name>-<connector_name>-secret。例如，my -broker-deployment-my-acceptor-secret。
即使接收器或连接器假设默认 secrete 名称，您仍然必须自己生成此 secret。它不会被自动创建。
4.7.2.1. 为主机名验证配置代理证书
本节论述了配置单向或双向 TLS 时必须生成的代理证书的一些要求。
当客户端在部署中尝试连接到代理 Pod 时，客户端连接 URL 中的 verifyHost 选项决定了客户端是否将代理证书的 Common Name(CN)与其主机名进行比较，以验证它们是否匹配。如果您在客户端连接 URL 中指定了 verifyHost=true 或类似的内容，客户端会执行此验证。
在很少情况下，当您对连接的安全性不担心时，您可能会省略此验证，例如，代理部署在隔离的网络中 OpenShift 集群上。否则，对于安全连接，建议客户端执行此验证。在这种情况下，正确配置代理密钥存储证书是确保客户端连接成功。
通常，当客户端使用主机验证时，您生成代理证书时指定的 CN 必须与客户端连接的代理 Pod 上的 Route 的完整主机名匹配。例如，如果您部署了单一代理 Pod，CN 可能类似如下：
CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
为确保 CN 可以在带有多个代理 的部署中解析到任何 代理 Pod，您可以指定一个星号(*)通配符字符来代替代理 Pod 的序号。例如：
CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
上例中显示的 CN 成功解析到 my-broker-deployment 部署中的任何代理 Pod。
另外，您在生成代理证书时指定的 Subject Alternative Name(SAN)必须 单独列出 部署中的所有代理 Pod，作为用逗号分开的列表。例如：
"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."
