红帽全球峰会4.6.2. 保护 broker-client 连接
如果您在接受或连接器（即将 sslEnabled 设置为 true）上启用了安全性，则必须配置传输层安全(TLS)以允许代理和客户端之间的基于证书的身份验证。TLS 是 SSL 的更新、更安全的版本。主要 TLS 配置有两个：
- 单向 TLS
- 仅代理提供证书。客户端使用证书来验证代理。这是最常见的配置。
- 双向 TLS
- 代理和客户端存在的证书。这有时称为 相互验证。
后续部分描述：
对于单向和双向 TLS，您可以通过生成存储代理和客户端之间成功 TLS 握手所需的凭证的 secret 完成配置。这是您必须在安全接受或连接器的 sslSecret 参数中指定的 secret 名称。secret 必须包含 Base64 编码的代理密钥存储（单向和双向 TLS）、Base64 编码的代理信任存储（仅双向 TLS），以及这些文件的对应密码（base64 编码）。单向和双向 TLS 配置流程演示了如何生成此 secret。
如果您没有在安全接收器或连接器的 sslSecret 参数中明确指定 secret 名称，接收器或连接器会假定默认 secret 名称。默认 secret 名称使用格式 <CustomResourceName>-<AcceptorName>-secret 或 <CustomResourceName>-<ConnectorName>-secret。例如，my-broker-deployment-my-acceptor-secret。
即使接收器或连接器假定默认 secrete 名称，您仍必须自行生成此 secret。它不会被自动创建。
4.6.2.1. 为主机名验证配置代理证书
本节论述了配置单向或双向 TLS 时必须生成的代理证书的一些要求。
当客户端尝试连接到部署中的代理 Pod 时，客户端连接 URL 中的 verifyHost 选项确定客户端是否将代理证书的通用名称(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 的 或dinal。例如：
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,..."
