使用Route 53搭配AWS负载均衡器时根域名SSL验证失败

• 通配符SSL证书的匹配规则天然不覆盖根域名：标准SSL协议中，*.domain.com的通配符仅匹配a.domain.com、b.domain.com这类一级子域名，不会匹配根域名domain.com本身，单独使用通配符证书必然会导致根域名SSL握手校验失败。
• 你遇到的「Chrome/Brave重试几次能访问、Firefox持续报错PR_END_OF_FILE_ERROR」是典型的DNS轮询命中异常节点表现：Route 53的根域名A记录配置了多个别名目标，其中部分目标（残留的旧负载均衡、未配置SSL的CloudFront分发、废弃的EC2实例）没有在443端口配置合法的根域名证书。客户端发起请求时按照DNS返回的IP轮询访问，前几次命中异常节点时SSL握手被直接重置触发错误；Chrome/Brave自带连接fallback重试机制，多次重试后命中配置正确的节点就能正常访问，Firefox对SSL握手失败的重试策略更严格，一旦握手失败就直接终止连接抛出错误，不会自动重试。
• 更换为仅覆盖domain.com的单域名证书后全站点报错是预期行为：这类证书不包含*.domain.com的SAN（主体备用名称）条目，所有子域名访问时都会触发证书域名不匹配的不安全提示。

• 登录Route 53控制台，进入对应域名的托管区域，找到根域名domain.com的A类型记录，列出所有关联的别名/多值应答目标，逐一核对每个目标是否是当前正在使用的业务资源，标记出已废弃、不属于当前架构的资源。
• 在本地终端多次执行dig domain.com（Linux/macOS）或者nslookup domain.com（Windows），收集所有返回的公网IP，和当前负载均衡器的节点IP段做比对，找出不属于负载均衡器地址池的异常IP。
• 对收集到的每个IP执行SSL握手测试：openssl s_client -connect <目标IP>:443 -servername domain.com，如果某个IP返回连接重置、握手超时、返回的证书不包含domain.com，即可确认是异常节点。
• 进入负载均衡器控制台，查看443端口HTTPS监听器绑定的证书详情，确认证书的SAN列表包含的域名范围。

• 清理Route 53根域名A记录中的所有无效目标，仅保留当前业务使用的负载均衡器作为唯一别名目标。注意根域名（区域顶点）不能配置CNAME记录，必须使用AWS提供的Alias别名记录类型指向负载均衡器。
• 重新申请ACM证书或者导入自定义SSL证书，确保证书的SAN列表同时包含domain.com和*.domain.com两个域名条目，不要使用仅覆盖单一根域名或仅覆盖通配符的证书。将新证书绑定到负载均衡器443监听器的默认规则上，如果存在多域名转发规则，要确认所有规则的证书配置一致。
• 如果架构中叠加了CloudFront、AWS Global Accelerator这类边缘加速服务，同步确认所有边缘节点的HTTPS监听器也绑定了同时覆盖根域名和通配符的证书，避免出现节点间证书配置不一致的问题。
• 配置生效后清空本地DNS缓存和浏览器SSL缓存，分别在不同浏览器的普通模式、隐私模式下多次刷新访问根域名和子域名，确认不再出现SSL连接错误。

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