Let's Encrypt 颁发的证书所包含的 CRL 链接完全被墙，可能导致所有用 LE 证书的网站在国内无法打开或者弹出警告。

[villivateur]

今天用 curl 访问我的网站，发现报错：

$ curl -vv https://www.example.com/generate_204
08:43:01.876922 [0-0] * Host www.vvzero.com:443 was resolved.
08:43:01.880422 [0-0] * IPv6: 2408:1:1013:e900::1
08:43:01.883004 [0-0] * IPv4: 1.116.4.74
08:43:01.885021 [0-0] * [HTTPS-CONNECT] added
08:43:01.887128 [0-0] * [HTTPS-CONNECT] connect, init
08:43:01.889315 [0-0] * [HTTPS-CONNECT] connect, check h21
08:43:01.891506 [0-0] *   Trying [2408:1:1013:e900::1]:443...
08:43:01.894156 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
08:43:01.896145 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
08:43:01.898445 [0-0] * [HTTPS-CONNECT] connect, check h21
08:43:01.901163 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
08:43:01.903526 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
08:43:01.907055 [0-0] * [HTTPS-CONNECT] connect, check h21
08:43:01.910135 [0-0] * schannel: disabled automatic use of client certificate
08:43:01.917094 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
08:43:01.919009 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
08:43:01.924728 [0-0] * [HTTPS-CONNECT] connect, check h21
08:43:01.933717 [0-0] * schannel: next InitializeSecurityContext failed: CRYPT_E_REVOCATION_OFFLINE (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline.
08:43:01.939440 [0-0] * [HTTPS-CONNECT] connect, all failed
08:43:01.941833 [0-0] * [HTTPS-CONNECT] connect -> 35, done=0
08:43:01.944171 [0-0] * closing connection #0
08:43:01.947391 [0-0] * [HTTPS-CONNECT] close
08:43:01.949490 [0-0] * [SETUP] close
08:43:01.952020 [0-0] * [SETUP] destroy
08:43:01.954525 [0-0] * [HTTPS-CONNECT] destroy
curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_REVOCATION_OFFLINE (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline.

然后尝试访问证书里提供的 CRL 链接：

$ curl -v http://e5.c.lencr.org/80.crl
* Host e5.c.lencr.org:80 was resolved.
* IPv6: 2606:4700::6812:15d5, 2606:4700::6812:14d5
* IPv4: 104.18.20.213, 104.18.21.213
*   Trying [2606:4700::6812:15d5]:80...
* Connected to e5.c.lencr.org (2606:4700::6812:15d5) port 80
* using HTTP/1.x
> GET /80.crl HTTP/1.1
> Host: e5.c.lencr.org
> User-Agent: curl/8.10.1
> Accept: */*
>
* Request completely sent off
* Recv failure: Connection was reset
* closing connection #0
curl: (56) Recv failure: Connection was reset

itdog 查询显示这个域名已经完全被墙，方法是 TCP RST 。

部分浏览器可能不会检查 CRL ，那就没问题。但可能更多的正规浏览器或者 APP 会检查，就会导致无法访问或者弹出警告。

小站站长可能会痛苦了，很多人可能没法上你的网站了。

[jeesk]

ZeroSSL 和 LetsEncrypt 都用上呀。

[billzhuang]

不都是用 OCSP 来检查的么？

[wasaibi12345]

虽然不是站长，但是 NAS 的域名用的是 lets encrypt 的证书，当初就觉得这个东西墙不墙完全看上面的心情，不安全

[wasaibi12345]

今天凌晨不是墙抽风了吗？有没有可能是这个原因？

[cheng6563]

浏览器上，实际上这些检查都只有 Firefox 在较为严格地执行
而且 OCSP 都快凉了
反正放心用完事

[billzhuang]

哦， 看到 lets encrypt 从 OCSP 切换到了 CRL 。

但主流浏览器和移动端也不检测 CRL 的吧

[vfs]

刚刚试了，crl 域名可以正常访问啊 (陕西西安）

[villivateur]

@wasaibi12345 跟今天凌晨墙抽风没关系，好像已经很久了


@cheng6563 这个是 CRL ，替代了 OSCP

[dorothyREN]

@jeesk zeroSSL 都不做证书业务了

[186526]

北京联通和北京阿里云稳定复现
但是在 Chrome 上 CRL 应该还是基于 CRLSet 批量更新的，影响不大

[jim9606]

有个比较极端的解决办法
换用 LE 新出的只有 7 天有效期的 shortlived 证书，这个直接没有 CRL 和 OCSP

[salmon5]

curl 会检查 CRL 吗？只有 FireFox 会强制检查 OSCP

[salmon5]

OSCP 因为隐私问题，马上要下线了

[yokisama]

怪不得我 Arch 更新 AUR 时一直提示 tls timeout
我一直开着软路由 passwall 但，但能访问网页无法通过 rpc 更新
原来是验证的域名被墙了...

[skiy]

@dorothyREN 不做证书业务的不是 ZeroSSL 吧？不做证书业务的好像是 Buypass 。
https://www.buypass.com/products/tls-ssl-certificates

[huangsijun17]

1. 上海联通打不开该 URL 。
2. 我看了我这个的 LE 证书，不是这个 CRL 地址。

[chenshaoju]

试了一下，http://e5.c.lencr.org/80.crl 确实被重置了。
但是看了一下我的网站用的 Let's Encrypt ，CRL 是 http://r11.c.lencr.org/43.crl ，这个暂时没问题。

[arrow629]

好像浏览器本来就没几个会实时查 CRL 吧，Chromium 用 CRLSet ，Firefox 用 OneCRL 。

[salmon5]

@salmon5 #13 OSCP 已经下线了 https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life

[MiKing233]

很早就发过了, 没什么好的解决方案
https://www.v2ex.com/t/1144666

[pingdog]

@salmon5 卧槽，当年提出 OCSP 来替代 CRL ，这就光荣退役了。。还是朴素无华的技术活得更久

[Virace]

@MiKing233 确实，早就这样了，切换到 zerossl 暂时还能用。 问题就是这个 zero 好像不支持有些域名，比如说.cc, 申请一直失败，这就很难受

[shihao9618]

公用名 (CN) E6
组织 (O) Let's Encrypt
好像还可以用

[vibbow]

还是得 ocsp

[villivateur]

@vibbow OCSP 也会被墙或者劣化。CRL 至少是周期性去获取的，OCSP 每次打开网站都会卡一下。

[bollld607]

南方某省电信，第一下能上，服务器响应 200 ok：
curl -v http://e5.c.lencr.org/80.crl
* Host e5.c.lencr.org:80 was resolved.
* IPv6: 2606:4700::6812:15d5, 2606:4700::6812:14d5
* IPv4: 104.18.21.213, 104.18.20.213
* Trying [2606:4700::6812:15d5]:80...
* Trying 104.18.21.213:80...
* Connected to e5.c.lencr.org (2606:4700::6812:15d5) port 80
* using HTTP/1.x
> GET /80.crl HTTP/1.1
> Host: e5.c.lencr.org
> User-Agent: curl/8.15.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Date: Wed, 20 Aug 2025 08:25:08 GMT

再试一下就被 reset 了：
curl -v http://e5.c.lencr.org/80.crl
* Host e5.c.lencr.org:80 was resolved.
* IPv6: 2606:4700::6812:15d5, 2606:4700::6812:14d5
* IPv4: 104.18.21.213, 104.18.20.213
* Trying [2606:4700::6812:15d5]:80...
* Trying 104.18.21.213:80...
* Connected to e5.c.lencr.org (104.18.21.213) port 80
* using HTTP/1.x
> GET /80.crl HTTP/1.1
> Host: e5.c.lencr.org
> User-Agent: curl/8.15.0
> Accept: */*
>
* Request completely sent off
* Recv failure: Connection reset by peer
* closing connection #0
curl: (56) Recv failure: Connection reset by peer

[salmon5]

谁能总结下：哪些浏览器、组件会验证 Let's Encrypt 的 CRL ，从而会被影响？那就功德无量了

[cheng6563]

@salmon5 应该没一个有。除非自己配置强制校验的策略。

[realpg]

用啥 le 的 acme 啊
直接用 google 的 就是签发服务器要翻墙
使用验证和 crl 都是墙内

[dianso]

完全不会，你是一点也不懂啊。

[cccer]

至少 Chrome 不会去下载和校验 CRL, 谷歌自己维护了一个压缩版的 CRLSet 。

[FarAhead]

流放之路国际服前段时间更新提示证书错误就是这个问题

[Fqy]

这个网站还能上么
https://www.huogua.net

[chinni]

用 sniproxy 代理下 google 签发的 域名，然后国内要签发证书的机器上 写一条 host ，就可以基本无缝使用 google 证书了。最简单的办法了，可以不管 le 的 奇怪问题和 zerossl 的不定时抽风

[wzw]

@chinni #34 google 证书 好用很多？

[FengkuiChan]

今天凌晨大概坏了半小时，然后又好了

[shijingshijing]

我记得 iPhone 点下图标启动 App 之前也会通过 OCSP 对 App 证书进行校验，难道苹果也抛弃了？
```
iPhone 上点击一个 App 时，系统会通过 OCSP 协议实时查询该 App 签名证书的状态，确保 App 的合法性和安全性。这一过程包括发送 OCSP 请求、接收并验证响应，最终决定是否允许 App 启动，从而保护用户免受潜在的安全威胁。
```

[DaDapeng]

请问微信内置浏览器会受影响吗？
@salmon5

[Zy143L]

@vfs 西安(移动) 已经寄了

[doruison]

@billzhuang ocsp 已经被 le 废弃了，性能开销大

[vfs]

@Zy143L 我的和你不是一个节点， ：C:\Users\xxx>curl -v http://r11.c.lencr.org/46.crl
* Host r11.c.lencr.org:80 was resolved.
* IPv6: (none)
* IPv4: 104.18.21.213, 104.18.20.213
* Trying 104.18.21.213:80...
* Connected to r11.c.lencr.org (104.18.21.213) port 80
* using HTTP/1.x
> GET /46.crl HTTP/1.1
> Host: r11.c.lencr.org
> User-Agent: curl/8.13.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Date: Thu, 21 Aug 2025 01:02:01 GMT

[leoking6]

@fuzzsh 没有退役，只是 letsencrypt 宣布不再提供这个服务了。说是隐私考量，其实应该是成本扛不住了吧

[dnsjia]

https://ssl.dnsjia.com 支持申请多个证书

[Zy143L]

@vfs #41 R11 的确实没问题 但是 E5 确实寄了

[salmon5]

@DaDapeng #38 母鸡啊，反正企业业务使用 DigiCert ，CRL 和 OCSP 都是 digicert.cn 的；当然 GlobalSign 的 CRL 和 OCSP 也是全球加速的

[vibbow]

@villivateur 有 OCSP stapling 呀，服务器提前获取好就行

[zhanghua0]

@yokisama aur 那个是正在被打，已经发新闻解释了，以及提供了点缓解措施。

[Tink]

我之前都换成 zero SSL ，目前暂时还没啥问题

[journalist]

我试了 e5.c 必断，其他数字随机抽风，akamai （ c 换成 i ）没事，不知道可不可以在本地做个重定向 https://subdomainfinder.c99.nl/scans/2025-08-20/lencr.org

[e3c78a97e0f8]

只有 windows 下的 curl 用了 SChannel 有这个问题，Linux 下的 curl 根本不报错

[e3c78a97e0f8]

我看 zerossl.com 和 google.com 的证书 CRL 都是 pki.goog 域名上，这也是被墙的域名。那用 GTS ACME 和 ZeroSSL ACME 签发的证书 CRL 是不是也是 pki.goog 上？如果也是，那换 ACME provider 不能解决这个问题。

[AkinoKaedeChan]

至今难以理解为什么要 ban 这个…