你确实踩了一个常见的理解误区——CloudFront的默认证书（*.cloudfront.net）只能用来验证CloudFront原生分配域名，哪怕客户端完全支持SNI，也没法直接用它来适配你的自定义备用域名（比如example.com）。

为什么会出现这个错误？ #

浏览器验证SSL证书时，会严格检查证书里的通用名称（CN）或主题备用名称（SAN）列表是否包含你当前访问的域名。CloudFront的默认证书里，SAN列表只有CloudFront自己的域名后缀，根本没有你的自定义域名，所以不管SNI是否生效，浏览器都会判定证书不匹配，直接抛出这个安全错误。

正确的配置逻辑（满足你的自定义域名HTTPS需求） #

要实现备用域名的HTTPS访问，你必须为自定义域名配置对应的SSL证书，步骤如下：

• 首先，去AWS Certificate Manager（ACM）申请包含你的自定义域名（比如example.com或*.example.com）的SSL证书，注意必须在us-east-1（美国东部弗吉尼亚北部）区域申请——因为CloudFront只能使用这个区域的ACM证书。
• 然后，回到你的CloudFront分配设置页面，找到「SSL证书」选项，切换到你刚申请的自定义证书。
• 确认你的自定义域名的DNS记录已经设置为CNAME，指向CloudFront分配的原生域名。
• 最后，等待CloudFront的配置更新生效（通常需要15-30分钟），之后再访问你的自定义域名，证书验证就能正常通过了。

补充：关于SNI的正确理解 #

SNI的作用是让CloudFront在同一个IP地址下，为不同的域名返回对应的证书——它是实现多域名共享IP的技术前提，但不是让默认证书能覆盖自定义域名的魔法。你还是得为每个自定义域名准备好对应的证书，CloudFront才能通过SNI把正确的证书返回给客户端。

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