关于erbaharlab.com子域名SSL证书配置与Sophos防火墙黑名单异常拦截的技术咨询

我们研究组的域名是erbaharlab.com，已经迁移到Cloudflare免费版托管NS记录，目前在用的子域名包括：

• www.erbaharlab.com：研究组主站，主域名erbaharlab.com会重定向到这里
• nanospacejm2.erbaharlab.com：会议注册站点（当前优先级最高，需要接收参会者注册）
• cdn.erbaharlab.com：静态资源站，基于Cloudflare Pages部署

近期我们遇到了防火墙拦截的奇怪问题：

在某使用Sophos防火墙的机构网络中，直接访问nanospacejm2.erbaharlab.com会被拉黑拦截；但如果先访问www.erbaharlab.com，再去访问会议子域名，就可以正常打开。这和我们预期的“被拉黑的子域名应该始终无法访问”完全不符。

我们的SSL证书现状：

• 当前www和nanospacejm2子域名使用的是通用名为erbaharlab.com、有效期至2024-05-09的证书
• cdn子域名使用独立的通用名为cdn.erbaharlab.com的证书
• CAA记录由Cloudflare自动生成，覆盖所有已注册的SSL证书

我们怀疑是不是SSL证书配置有误导致了防火墙的误拦截？如果确认SSL配置没问题，又该如何验证这一点？另外，有没有其他可能的配置问题导致这种奇怪的访问差异？

排查建议（从SSL到Cloudflare/防火墙规则） #

一、先确认SSL证书相关的潜在问题 #

1. 检查证书的SAN字段覆盖
   你提到www和nanospacejm2共用主域名证书，务必确认这个证书的SAN（Subject Alternative Name）字段明确包含nanospacejm2.erbaharlab.com。有些严格的防火墙会校验证书是否精准覆盖访问的子域名，若SAN里没列全，可能直接判定为不安全拦截；但先访问www后，防火墙可能缓存了证书的信任状态，后续访问子域名时直接复用信任链。

   • 本地验证命令：

     openssl s_client -connect nanospacejm2.erbaharlab.com:443 | openssl x509 -noout -text | grep -A 10 "Subject Alternative Name"
     

     看输出里是否有DNS:nanospacejm2.erbaharlab.com。

2. 验证证书链完整性
   部分防火墙（比如Sophos）会严格校验SSL证书链是否完整，如果nanospacejm2的证书链缺失中间证书，直接访问时会被判定为证书不合法；但先访问www后，防火墙缓存了完整的证书链，后续访问子域名时信任链已存在，所以放行。

   • 可以用本地命令对比www和nanospacejm2的证书链：

     # 查看nanospacejm2的证书链
     openssl s_client -connect nanospacejm2.erbaharlab.com:443 -showcerts
     # 查看www的证书链
     openssl s_client -connect www.erbaharlab.com:443 -showcerts
     

     确认两者的证书链是否一致，是否都包含完整的根证书和中间证书。

3. 核对CAA记录与证书颁发机构
   虽然Cloudflare自动生成了CAA记录，但还是要确认CAA是否允许给nanospacejm2颁发证书的CA。如果CAA记录遗漏了对应的CA，防火墙可能认为证书不合法而拦截。

   • 本地查询CAA记录：

     dig erbaharlab.com CAA
     

     确认返回的记录里包含当前证书的颁发机构（比如Cloudflare的CA或Let's Encrypt）。

二、排除SSL问题后的其他排查方向 #

如果确认SSL配置全没问题，那大概率是Cloudflare的路由逻辑或Sophos防火墙的规则/缓存问题：

1. Cloudflare共享IP与路由差异
   Cloudflare免费版使用共享IP池，可能某个共享IP被Sophos拉黑过。直接访问nanospacejm2时解析到的是被拉黑的IP；但先访问www后，Cloudflare可能分配了未被拉黑的IP，或者Sophos缓存了www的IP信任状态，后续访问子域名时复用了这个会话的IP。

   • 验证方法：分别在“直接访问nanospacejm2”和“先访问www再访问nanospacejm2”两种场景下，ping子域名看返回的IP是否一致；同时在Cloudflare里给nanospacejm2开启始终使用HTTPS和自动HTTPS重定向，确保所有访问都是HTTPS，避免HTTP请求触发额外拦截。

2. Sophos防火墙的规则与缓存逻辑
   有些Sophos防火墙会基于“会话上下文”放行请求：如果先访问了一个被归类为“可信”的域名（比如www属于教育研究类），后续同会话内的子域名访问会被认为是可信的，绕过了单独的分类检查。而直接访问nanospacejm2时，防火墙可能把它误归类为“可疑站点”或命中了IP黑名单。

   • 解决方向：联系该机构的IT部门，查询Sophos的拦截日志，看具体的拦截原因（是IP黑名单、网站分类错误还是证书不信任）；同时可以在Cloudflare的支持页面提交子域名到Sophos的误报申诉通道，请求解除拉黑。

3. Cloudflare子域名配置差异
   检查nanospacejm2和www在Cloudflare的配置是否一致：比如是否都开启了橙色云代理模式、是否有不同的页面规则/WAF规则。如果nanospacejm2没开代理，直接解析到源站IP，而源站IP被Sophos拉黑；但www开了代理用Cloudflare IP，先访问www后，浏览器复用了代理会话，后续访问子域名时走的是Cloudflare IP而非源站IP，所以能访问。

   • 验证方法：在Cloudflare的域名面板里，查看两个子域名的“代理状态”，确保都是“橙色云”（完全代理），让所有访问都走Cloudflare的IP，避免源站IP暴露被拉黑。

三、快速验证SSL是否存在问题的小技巧 #

1. 跨环境测试：在不同网络（比如手机流量、其他机构网络）访问nanospacejm2，看是否只有Sophos环境有问题，排除通用的SSL错误。
2. 手动信任证书：在Sophos环境的机器上，手动导入nanospacejm2的根证书，再尝试访问，看是否能正常打开，排除证书不被信任的问题。
3. 对比Cloudflare日志：查看Cloudflare的访问日志，对比直接访问nanospacejm2和先访问www再访问的请求差异（比如IP、SSL握手状态、返回码），找出行为不同的原因。

备注：内容来源于stack exchange，提问作者Eftal Gezer