注意,仅在生成密钥对时包含“SAN”是不够的。
keytool \
-keystore kafka.server.keystore.jks \
-alias {alias} \
-validity {validity} \
-genkey \
-keyalg RSA \
-ext SAN=DNS:{FQDN}
这需要在创建证书签名请求时也包括“SAN”。
keytool \
-keystore kafka.server.keystore.jks \
-alias {alias} \
-certreq -ext SAN=DNS:{FQDN}
-file {csr_filename}
可以验证创建的证书签名请求,并且应该具有相关的“SAN”。
keytool \
-v -printcertreq -file {csr_filename}
最后,如果使用openssl的x509命令来满足证书签名请求,则应特别注意明确包括x509版本3扩展名。 "SAN"就是这样的扩展名,除非明确包含,否则将无法进入最终发出的证书。
这个错误通常发生在 SSL/TLS 连接中,当 SSL/TLS 服务器使用了一个没有包含正确主机名的证书时,就会发生该错误。这意味着 SSL/TLS 客户端无法验证 SSL/TLS 服务器的身份,因为没有提供与主机名相匹配的主题替代名称(SAN)或通配符名称。解决这个问题的方法是,在 SSL/TLS 服务器的证书中包含正确的 SAN 或通配符名称,以便 SSL/TLS 客户端可以验证证书并与服务器建立安全连接。
看起来你的 brokers 证书中缺少Subject(Subject Alternative Name,SAN)(例如 /var/private/ssl/kafka.server.truststore.jks)。
请在 keytool 命令中添加参数 -ext SAN=DNS:{FQDN}
:
keytool \
-keystore kafka.server.keystore.jks
-alias localhost
-validity {validity}
-genkey
-keyalg RSA
-ext SAN=DNS:{FQDN}
在创建服务器密钥库时,请确保包括 SAN:
如果启用主机名验证,则客户端将针对以下两个字段之一验证服务器的完全限定域名(FQDN):
这两个字段都是有效的,但是 RFC-2818 建议使用 SAN。SAN 也更灵活,允许声明多个 DNS 条目。另一个好处是,CN 可以设置为更有意义的值,用于授权目的。
或者,你可以选择禁用服务器主机验证:
通过将 ssl.endpoint.identification.algorithm
设置为空字符串来禁用服务器主机名验证。
因此,你只需要在 server.properties 中设置以下配置,然后重新启动 Kafka 集群即可:
ssl.endpoint.identification.algorithm=