zzz

注意，仅在生成密钥对时包含“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）：

1. 通用名称（Common Name，CN）
2. 主题备用名称（Subject Alternative Name，SAN）

这两个字段都是有效的，但是 RFC-2818 建议使用 SAN。SAN 也更灵活，允许声明多个 DNS 条目。另一个好处是，CN 可以设置为更有意义的值，用于授权目的。

或者，你可以选择禁用服务器主机验证：

通过将 ssl.endpoint.identification.algorithm 设置为空字符串来禁用服务器主机名验证。

因此，你只需要在 server.properties 中设置以下配置，然后重新启动 Kafka 集群即可：

ssl.endpoint.identification.algorithm=

参考：https://www.orchome.com/171

你调试好了吗，我也是安装了好几遍没有成功

你搜索下这篇文章的 localhost 

是在创建时 提示输入 姓名姓式这个位置设置成服务器的ip吗