使用Route 53 CNAME连接AWS MSK集群遇SSL错误，能否兼容IAM认证？

首先咱们得先理清你遇到的问题根源：你用自定义CNAME b-1.msk.sandbox.internal.company.com 指向MSK的原生域名，但MSK默认使用的AWS签发证书，仅包含*.msksandbox.nrfnuy.c42.kafka.us-east-1.amazonaws.com这类AWS域名作为Subject Alternative Name（SAN）。当Kafka客户端连接自定义域名时，TLS握手阶段会验证服务器证书的SAN是否匹配当前连接的域名，不匹配就会抛出你看到的CertificateException——这个问题和IAM认证无关，是TLS层的基础验证逻辑，不管用哪种认证方式都得先解决它。

回到你的核心问题：在IAM认证的场景下，Route 53完全可以和MSK协同工作，但必须先解决SSL域名不匹配的问题，否则连TLS握手都过不了，IAM认证根本没机会触发。下面给你几个可行的解决思路：

1. 直接使用MSK原生域名（最简便） #

放弃自定义CNAME，直接用AWS提供的MSK域名b-1.msksandbox.nrfnuy.c42.kafka.us-east-1.amazonaws.com连接集群。这种方式完全避开了SSL域名验证问题，配置简单，适合快速解决问题。

2. 给MSK配置自定义SSL证书（生产环境推荐） #

你可以通过AWS Certificate Manager（ACM）创建包含自定义域名b-1.msk.sandbox.internal.company.com的证书，然后更新MSK集群的安全配置，替换默认的AWS签发证书。具体步骤大概是：

• 在MSK集群所在的us-east-1区域，用ACM申请一张包含自定义域名的证书（支持通配符，比如*.msk.sandbox.internal.company.com）
• 进入MSK集群的配置页面，修改安全配置，选择你刚创建的ACM证书
• 等待集群配置更新完成后，客户端连接自定义CNAME时，证书的SAN会包含该域名，就能正常通过SSL验证了

注意：MSK要求自定义证书必须是ACM签发的，且和集群在同一AWS区域。

3. 临时关闭客户端的SSL域名验证（仅测试环境可用） #

如果你只是在测试环境临时验证功能，可以修改Kafka客户端的SSL配置，关闭域名验证。具体是在客户端配置中添加：

ssl.endpoint.identification.algorithm=

这个配置会让客户端跳过TLS握手时的域名匹配检查，但强烈不推荐在生产环境使用——这会移除TLS的关键安全防护，可能导致中间人攻击。

最后再强调下：IAM认证负责的是客户端身份的校验（比如验证你的AWS IAM凭证是否有权限访问MSK），而DNS解析（Route53）和SSL证书验证是独立的前置环节。只要解决了SSL域名匹配的问题，Route53配合IAM认证的MSK集群完全可以正常工作。

内容的提问来源于stack exchange，提问作者Dmitry