EC2场景下AWS ACM通配符SSL证书浏览器报无效问题排查

首先澄清你对A记录配置的误解：Route 53的A记录指向带.amazonaws.com后缀的负载均衡域名，根本不会导致证书匹配失败。SSL校验的核心逻辑从来不是看解析记录指向哪个域名，而是浏览器会把你地址栏输入的域名（比如mydomainname.com、www.mydomainname.com），和负载均衡返回的证书上列明的可信任域名做比对。你签的*.mydomainname.com通配符证书，本身就覆盖了所有该主域下的二级域名，哪怕你把域名解析到AWS的IP上，这个匹配关系也是完全成立的。

浏览器报证书无效、但公网检测显示正常的常见触发原因 #

• DNS缓存残留导致访问到旧服务：这是出现这类矛盾现象的最高概率原因。修改Route 53记录后，你的本地设备、家用路由器、运营商递归DNS节点，可能仍然缓存着旧的IP地址，这些旧IP对应的服务器或旧负载均衡上部署的不是你新申请的ACM证书。公网第三方检测工具的节点直接从权威DNS拉取最新解析记录，会正常访问新的负载均衡、拿到正确的证书，因此显示状态正常，只有本地环境会因为缓存走到旧服务拿到不匹配的证书。
• 负载均衡HTTPS监听器配置错误：
  • 虽然你已经将新证书关联到负载均衡，但监听器配置里可能仍保留旧的不匹配证书，甚至错误开启了全量HTTP跳转，导致实际HTTPS连接时返回的不是你绑定的新证书
  • 如果负载均衡开启了基于SNI的多证书绑定，顺序配置错误时会优先返回AWS自带的默认证书（该证书仅匹配AWS自有域名，和你的域名不匹配）。此时公网检测可能因为检测时的SNI匹配规则走到正确的证书，而本地浏览器的SNI请求格式略有差异，就会拿到不匹配的默认证书。
• 本地客户端的HTTPS流量拦截：如果本地设备开启了HTTPS抓包代理、企业安全软件、VPN类工具的流量拦截功能，这些工具会主动替换链路中的SSL证书，导致浏览器提示证书无效。这类问题属于本地客户端的链路劫持，完全不会影响公网第三方工具的检测结果。

关于生效等待时间的说明 #

• AWS侧的配置（ACM证书同步到负载均衡、Route 53权威记录更新）本身的生效周期通常在5分钟以内，不存在需要数小时等待的情况
• 真正需要等待的是Route 53记录中配置的TTL时长：比如设置的TTL为300秒，各级递归DNS最长需要5分钟即可完成记录同步。如果超过这个时长仍出现证书报错，就不属于生效延迟的范畴，需要按上面的几个点逐一排查。

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