跨账号VPC Endpoint场景下HTTPS连接建立失败问题咨询

核心问题本质：TLS握手阶段的证书校验逻辑，会校验客户端请求携带的SNI域名是否存在于服务端返回证书的SAN扩展列表中。当前客户端实际访问域名为server.bar.com，服务端绑定的SSL证书仅覆盖*.foo.com，二者不匹配必然触发校验失败，以下是可直接落地的修复方案，按改造成本从低到高排序：

方案1：扩展服务端证书SAN列表（改造成本最低，无侵入） #

• 操作步骤：在服务端账号的证书管理服务中，为现有SSL证书追加SAN值，将server.bar.com加入证书覆盖域名范围；也可以直接申请新的多域名证书，同时覆盖*.foo.com和server.bar.com，将新证书绑定到NLB的HTTPS监听器即可。
• 校验逻辑：客户端发起HTTPS请求时SNI携带server.bar.com，NLB返回的证书包含该域名，直接通过校验，不需要调整现有解析配置、客户端请求逻辑。
• 注意事项：申请追加SAN时需要完成bar.com的域名所有权验证，由于你方持有客户端账号bar.com托管区域的管理权限，直接在托管区添加对应的验证解析记录即可完成校验，无平台规则阻碍。

方案2：客户端侧使用服务端原有域名发起请求，配合私有DNS解析（无需修改证书） #

• 操作步骤：
  1. 放弃在bar.com公共托管区创建指向VPC Endpoint的解析记录，在客户端账号内创建关联业务VPC的foo.com私有托管区域。
  2. 在该私有托管区内创建server.foo.com的Alias记录，直接指向客户端账号内的VPC Endpoint。
  3. 将客户端侧的请求地址从server.bar.com调整为server.foo.com。
• 校验逻辑：客户端请求server.foo.com时，私有DNS将域名解析到VPC Endpoint，TLS握手时SNI携带server.foo.com，与服务端现有*.foo.com证书完全匹配，校验通过。
• 注意事项：私有托管区域仅在关联的VPC内生效，不会影响VPC内访问foo.com下其他公网域名的正常解析，未显式配置的foo.com子域名默认仍走公网解析链路。

方案3：服务端侧部署SNI代理层（适合无证书修改权限、无客户端逻辑调整权限的场景） #

• 操作步骤：将现有NLB的HTTPS监听器后端替换为支持SNI识别的反向代理层（可选用ALB、Nginx集群），代理层同时绑定两张SSL证书：原有的*.foo.com证书、单独申请的覆盖server.bar.com的证书，代理层根据客户端请求携带的SNI值返回对应证书，完成TLS握手后将请求透传给后端EC2服务。
• 校验逻辑：客户端请求server.bar.com时，代理层识别SNI返回匹配的bar域名证书，完成TLS建连后透传业务流量，现有客户端解析、后端服务配置都不需要调整。

禁止通过客户端侧关闭HTTPS证书校验的方式绕过问题，该操作会引入中间人攻击风险，不符合生产环境安全合规要求。

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