iOS 端似乎对 Caddy 自动生成的证书兼容性差一些?

[vincentWdp]

微信小程序的二级页面都是 h5, 昨天发现, 在苹果手机上访问这些二级页面, 都无法加载数据. 使用手机上的 Safari 和 Chrome 访问 h5 网址也无法加载数据, 但苹果电脑的 Safari 和 Chrome 可以访问. 安卓手机没有任何问题.

后面用数据线连接手机和电脑, 在电脑的 Safari developer 选择手机设备进行网页 inspect, 才查到报错原因: 后端域名证书过期 2 天了.

可后端域名证书还有 58 天才过期, 因此推断 Caddy 更新证书后, iOS 端在一个月内没有跟着更新, 还在使用上次的证书.

最开始, 我清理了微信缓存, 在我手机上可以正常访问 h5 了, 但同事同样操作却不行...

最终解决方法就是换回 Nginx, 然后使用 certbot 生成证书, 服务恢复.

期间, 我还用 钉钉、飞书、知乎这些 App 自带的浏览器进行测试, 依旧报错.

但是, 我看了两个证书(Caddy 和 certbot)之间似乎没什么区别, 不知道 Caddy 的为什么不能用. 我和同事调侃, 我猜把 Caddy 现在维护的证书删掉, 让它重新生成一个证书, 应该也能解决问题, 但是算了不折腾了, 就 Nginx 吧...

[jeesk]

oscp 方向排查一下呢？

[jeesk]

说错了是 ocsp 校验

https://www.timestack.me/code/467/speed-up-ssl-verification-on-iphone-for-let-s-encrypt-cert-by-OCSP

[vincentWdp]

@jeesk 谢谢推荐. 但我感觉似乎不是这个原因, 因为无论是 Caddy 还是 certbot 获得的证书, 都是 let's encrypt 颁发的. 因此我也疑惑, 为什么会这样...

[yinmin]

证书不会在客户端缓存的。iOS 访问 https 优先使用 ECH ，其他的操作系统一般不会优先使用 ECH 。我猜测，也许你的问题是 ECH 配置错误造成的。

找一个 dig 版本较新的 (ubuntu 20.04 或者 debian 11 以上)，运行：
dig @223.5.5.5 subdomain.yourdomain.com https 看配置是否有问题。

举一个示例：查看 www.cloudflare.com 的 ECH
dig @223.5.5.5 www.cloudflare.com https
结果是：
www.cloudflare.com. 1 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.16.123.96,104.16.124.96 ipv6hint=2606:4700::6810:7b60,2606:4700::6810:7c60

iOS 会使用 ipv4hint 和 ipv6hint 的地址去访问服务器，不再使用 A/AAAA 记录。如果你的 DNS type65( https)配置有误，或者是 DNS type65 的 ttl 有误，会导致 iOS 连接了发生错误。

[yinmin]

另外，公司生产环境建议不要使用 Let's Encrypt 免费证书。因为某些地方在某些时期会无法访问使用 Let's Encrypt 证书的网站。公司生产环境还是购买收费证书稳妥。

[Romic]

@yinmin 那么问题来了，比如 aws 和阿里云都有提供免费的证书，实际上我们也使用过这些免费证书，感觉还挺稳定的。除了时间短一点，那么和 Let's Encrypt 区别在哪？无非就是付费和免费的人力投入度的问题？

[yinmin]

@Romic #6 不是技术的问题，是因为太多的人用 let’s encrypt 证书来加密翻墙。

[vincentWdp]

@yinmin 🤣是这样的

[vincentWdp]

@jeesk
@yinmin
答案找到了, 我服务器上 caddy 版本是 2.6.2, 有个 bug: quic 协议监听器缓存了证书, 但在证书更新时, 没有更新缓存, 2.7.x 修复了这个 bug. 而恰好 iOS 端的 app 自带的 WebKit 是早在 iOS15 就优先使用了 quic 协议(quic 握手成功了, 但后续证书验证失败了, 而握手成功使得协议没有回退到 h2/h1), 导致这个 bug 出现.