Azure Front Door Standard自定义域HTTPS报0x830c1011证书错误排查

查看Front Door发往源站实际请求的方法 #

• 开启诊断日志中的访问日志与健康探测日志：在Front Door诊断设置里勾选FrontDoorAccessLog、FrontDoorHealthProbeLog两类日志，投递到Log Analytics工作区即可查询到Front Door向源站发起请求的全量请求头、TLS握手错误详情、源站响应状态码，不需要在源站侧额外配置就能拿到请求侧的完整数据。
• 源站侧抓包校验：在源站入口服务器/防火墙上，针对Azure Front Door的官方公网IP段抓443端口的报文，可直接查看TLS握手过程与完整HTTP请求内容，Front Door发往源站的请求会携带X-Azure-FDID专属头，可作为过滤标识。
• 调整源站Web服务日志级别：临时把Nginx、Apache、IIS等Web服务的日志调整为debug级别，记录所有入站请求的TLS协商过程、请求头、请求路径，重点筛选来自Front Door边缘节点IP的请求记录。

错误0x830c1011 The certificate authority is unfamiliar的常见诱因 #

该错误的本质是Front Door边缘节点与源站进行TLS握手时，无法构建到受信任根的证书链。本地curl、openssl检测正常不代表证书配置完全符合Front Door的校验逻辑，常见诱因如下：

• 证书链合并顺序错误或缺失中间证书：Go Daddy通配符证书的合并顺序必须严格为用户服务器证书 -> 二级中间证书 -> 一级中间证书，不能颠倒顺序，也不能漏带任意一级中间证书。本地openssl/curl校验时会自动从系统信任库补全缺失的中间证书，导致误判为配置正常；但Front Door不会自动拉取缺失的证书链节点，只要返回的链不完整就会报CA不可信。校验时不要给openssl加-CApath、-CAfile类指定信任库的参数，直接执行openssl s_client -connect 源站域名:443 -showcerts查看返回的证书链是否完整、顺序是否正确。
• SNI配置不匹配：如果源站服务器托管了多个HTTPS站点，Front Door发起TLS握手时携带的SNI值必须和源站对应站点绑定的证书域名匹配，否则源站会返回默认站点的自签名证书/其他CA签发的错误证书。注意Front Door默认携带的SNI值是你在源站配置中填写的源站主机地址，不是自定义域的域名，若未手动修改源站主机头配置，极易出现SNI匹配错误。
• 证书链包含异常交叉签名证书：Go Daddy部分老根证书存在多个交叉签名版本，若合并证书时夹带了过期的交叉签名证书、或同一条链中同时存在新旧两个信任路径的证书，Front Door的TLS栈构建信任路径时可能走到不可信分支，即便其中一个根在微软受信任列表中也会报错。
• TLS版本或加密套件不兼容：若源站仅开启TLS1.0/1.1等低版本协议，或配置了Front Door不支持的加密套件，TLS握手协商失败时也可能抛出该误导性的CA错误，需确认源站已开启TLS1.2及以上版本，兼容Front Door支持的加密套件集合。
• 证书基础字段不符合校验要求：比如源站服务器本机时间异常导致证书被判定为未生效/过期、证书密钥用法字段未包含服务器身份验证目的、证书SAN列表未包含源站主机名，这些问题在本地测试时如果跳过主机名、有效期校验很容易被遗漏，但Front Door会做全字段严格校验。

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