一张证书引发的噱案

[felix021]

- 引 -

我也没想到在神策数据这大半年能遇到好几次和证书相关的问题。

- 起 -

2021 年 9 月 3 号，一个新客户接入到我们的 SaaS 系统。在某个环节，我们会给客户发个 HTTPS 请求，没想到竟然遇到了个 SSLHandshakeException:

Caused by: javax.net.ssl.SSLHandshakeException: ... unable to find valid certification path to requested target

在服务器上用 curl 试一把，也报错：

$ curl -v https://some.domain/
CAfile: /etc/pki/tls/certs/ca-bundle.crt
...
curl: (60) Peer's Certificate issuer is not recognized.

但用浏览器打开这个 URL ，却是没问题的，这说明问题应该出在我们的服务器端。

- 析 -

我们知道，HTTPS 是靠证书保证通信安全的；但客户端如何保证服务端给的证书是可信的呢？

由于证书总是由某个证书颁发机构（ Certificate issuer ，或 Certificate Authority ，简写成 CA ）签发的，如果我们事先将一批可信的证书颁发机构存储在本地，就可以在发起请求的时候判断证书是否可信了。

有时情况会更复杂一些：某些机构不在我们的列表里，但他的证书是由我们信任的某个机构颁发的，我们也认为他是可信的，因此他颁发的证书也是可信的。

于是这就构成了一个信任链，链的末端是「根证书颁发机构」（ Root CA ），这些机构通常是国际上公认可靠的大型机构，或者国家权威机关背书的机构。

理解了这点，就可以推测，应当是我们服务器上的机构列表没有及时更新；只要把该客户证书的颁发机构加入本地的列表就应该能解决该问题。

- 解 -

再细看上面 curl 命令的输出，有一行 CAfile: /etc/pki/tls/certs/ca-bundle.crt，这就是 curl 使用到的证书颁发机构列表。

以 www.baidu.com 为例，我们可以通过如下命令获取客户证书的信任链：

$ openssl s_client -showcerts -servername server -connect www.baidu.com:443 > cacert.pem

在得到的 cacert.pem 中，我们可以看到如下内容（略作简化)：

Certificate chain
 0 s:/CN=baidu.com
   i:/CN=GlobalSign Organization Validation CA - SHA256 - G2

-----BEGIN CERTIFICATE-----
MIIKQDCCCSigAwIBAgIMEZhyT2Z0o9Yhv76iMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
...(略)...
n3XcFtwQLBY9Iuqh8Mn7vtiv5k2azdGsYhZcFBCBAeUoRhDC
-----END CERTIFICATE-----

 1 s:/CN=GlobalSign Organization Validation CA - SHA256 - G2
   i:/OU=Root CA/CN=GlobalSign Root CA

-----BEGIN CERTIFICATE-----
MIIEaTCCA1GgAwIBAgILBAAAAAABRE7wQkcwDQYJKoZIhvcNAQELBQAwVzELMAkG
...(略)...
K1pp74P1S8SqtCr4fKGxhZSM9AyHDPSsQPhZSZg=
-----END CERTIFICATE-----

...(略)...

可以看到里面有两段用 --BEGIN CERTIFICATE-- 和 --END CERTIFICATE-- 包起来的 base64 编码字符串，这就是被编码为 PEM 格式（ Privacy Enhanced Mail ）的证书了（有时也会用 .crt 作为扩展名）。

在 BEGIN 前面有一些摘要，可以帮助我们了解证书的内容，比如 s:/CN=baidu.com 表示这个证书的主体（ s 即 subject ）是 baidu.com （ CN 即 common name ），i:/CN=GlobalSign 表示它的颁发机构（ i 即 issuer ）是 GlobalSign 。

因此可以看到，这个 cacert.pem 实际上包含了两个证书，一个是百度使用的证书，另一个是颁发该证书的 GlobalSign 这个机构（ CA ）自己的证书。

通过 curl --cacert cacert.pem https://www.baidu.com 我们可以确认，这个信任链能用来验证 www.baidu.com 的证书（实际上我们只需要里面第二个证书，将第一个证书删除，不影响 curl 的执行）。

回到该客户的情况，我们用相同的方法取得客户证书颁发机构的证书，将它放到 /etc/pki/ca-trust/source/anchors/ 目录，执行 update-ca-trust 将其加入到证书列表中，就可以正常使用 curl 命令来请求了。

- 然 -

没有「但是」的文章不是好文章。

curl 正常了，但是我们的 Java 代码依然报错，这说明 java 和 curl 使用了不同的 CA 列表。

问题倒是好解决，简单搜索一下，就了解到 jre 的证书是存放在 $JAVA_HOME/jre/lib/security/cacerts 这个文件里，需要使用专门的 keytool 工具来更新它：

$ keytool -import -trustcacerts -file cacert.pem -alias 证书颁发机构的名称 -keystore $JAVA_HOME/jre/lib/security/cacerts

Enter keystore password:  changeit （这是 jre 自带的默认密码）

Certificate was added to keystore

再次验证，Java 代码就可以正常运行了。

注：如果想要单独验证某个证书，可以这样

• (1) 先创建一个空的 keyStore （密码为 storePassword ）：

$ keytool -genkeypair -alias boguscert -storepass storePassword -keypass secretPassword -keystore keystore -dname "CN=Developer"
$ keytool -delete -alias boguscert -storepass storePassword -keystore emptyStore.keystore

• (2) 添加证书到该 keyStore：

$ keytool -import -trustcacerts -file cacert.pem -alias 机构名称 -keystore keystore

• (3) 指定 keyStore 启动 java 程序：

$ java -Djavax.net.ssl.trustStore=keystore -Djavax.net.ssl.trustStorePassword=storePassword -cp $CLASS_PATH CLASS_NAME

- 劫 -

不巧的是，这周又遇到了一个证书信任的问题，这次是客户的环境向我们的服务器发起请求，报了相同的错误。

有了前车之鉴，上面这些命令执行起来可谓得心应手，但是这次却不灵了。

排查过程比较琐碎，也因为陷入思维定势而走了一些弯路，但其实原因很简单，这里就不卖关子了。

这家客户是一家泛金融类的企业，其生产环境的网络安全级别非常高，不仅有严格的外网访问限制，而且针对所有 https 请求都会默认劫持，用一个自签名证书返回错误信息。

经过与客户沟通，将神策数据的域名添加到白名单后，问题得以解决。

- 故事 -

讲完了事故，再讲讲故事。

非对称加密、证书、信任链这一系列发明，构成了现在 web 通信安全的基石，很难想象如果没有这些基础设施，现在互联网还能做些什么。

但是这里隐藏了一个大 bug：我们凭什么相信本地这些证书颁发机构是可信的？

至少有三种情况会打破这个假设：

• 本地 CA 列表被污染

可能你的电脑 /手机被病毒导入了 CA 证书；或者你自己可能就做过这个事情，比如公司网管要求添加公司的自签名证书，又或者你为了能使用 Charles 来抓 https 请求，导入了它自签名的 Root CA 证书。

• 机构的私钥泄漏

我没有在公开渠道查到相关的事故（倒是有一个代理商把客户证书的私钥给泄漏了）；如果某个机构的私钥泄漏，这家机构应该离倒闭也不远了。

• 看起来正经的机构也可能不正经

各国政府控制的 CA 机构大概都干过些「不干净」的事情（至少有这种冲动），有一些被发现了，有一些还没有。出于本文的安全考虑，这里就不展开细节了。此外，「不被政府控制」的那些机构，就一定干净么？说到底，机构总是被所在国管辖的，当遇到政府行政命令的时候，不一定有反抗的能力。

综上，理论上并不存在 100% 可靠的通信安全方案。

如果你的应用对通信安全要求非常严格，连本地的 CA 列表都不相信，可以考虑加入更多的手段来提高通信的安全等级。

简单一点的场景（例如 app 不想被抓包破解协议），可以自己校验服务器的证书（证书指纹，或者自己指定证书颁发机构列表）；要求更高的场景（例如需要访问内部控制系统），可以给客户端颁发证书，浏览器会在请求时提供证书用于校验，感兴趣的话可以参考 这个不太完善的项目。

- 收 -

结尾照例做一个小结：

1. HTTPS 是基于证书链来保证通信安全的；
2. 信任的基石是本地的证书颁发机构（ CA ）列表；
3. 可以通过向本地列表添加 CA 证书的方式来解决需要信任的证书；
4. 本地的 CA 不一定都是可信的；
5. 可以通过更严格的校验，或者客户端证书来加强通信的安全等级。

最后，神策在北京、上海、成都、武汉、深圳等多地均在招聘开发、产品、QA 等岗位，感兴趣的小伙伴欢迎私信勾搭；也可以点击我的 内推链接 查看 JD 并投递简历。

关注公众号，查看更多历史文章

   ▄▄▄▄▄▄▄   ▄      ▄▄▄▄ ▄▄▄▄▄▄▄  
   █ ▄▄▄ █ ▄▀ ▄ ▀██▄ ▀█▄ █ ▄▄▄ █  
   █ ███ █  █  █  █▀▀▀█▀ █ ███ █  
   █▄▄▄▄▄█ ▄ █▀█ █▀█ ▄▀█ █▄▄▄▄▄█  
   ▄▄▄ ▄▄▄▄█  ▀▄█▀▀▀█ ▄█▄▄   ▄    
   ▄█▄▄▄▄▄▀▄▀▄██   ▀ ▄  █▀▄▄▀▄▄█  
   █ █▀▄▀▄▄▀▀█▄▀█▄▀█████▀█▀▀█ █▄  
    ▀▀  █▄██▄█▀  █ ▀█▀ ▀█▀ ▄▀▀▄█  
   █▀ ▀ ▄▄▄▄▄▄▀▄██  █ ▄████▀▀ █▄  
   ▄▀▄▄▄ ▄ ▀▀▄████▀█▀  ▀ █▄▄▄▀▄█  
   ▄▀▀██▄▄  █▀▄▀█▀▀ █▀ ▄▄▄██▀ ▀   
   ▄▄▄▄▄▄▄ █ █▀ ▀▀   ▄██ ▄ █▄▀██  
   █ ▄▄▄ █ █▄ ▀▄▀ ▀██  █▄▄▄█▄  ▀  
   █ ███ █ ▄ ███▀▀▀█▄ █▀▄ ██▄ ▀█  
   █▄▄▄▄▄█ ██ ▄█▀█  █ ▀██▄▄▄  █▄  

[imes]

你到底是推销 github 项目？还是招聘广告？还是公众号推广？我现在思路有点乱，反应不过来。

[maleclub]

@Liv

[maleclub]

@Livid

[oneisall8955]

@maleclub livi🐶

[yuzo555]

一个 CA 证书都能水一篇文的公司，技术水平大家可以掂量下，一定很适合摸鱼，各位羊毛摸鱼党不要错过

[yuzo555]

原来是内推不是直招，那可能是按人头计费的，收回 #5 的话，不能便宜楼主了

[choury]

你们为什么不像百度一样，让服务器把中间证书也发过来？

[jiuhuicinv]

看不懂

[felixcode]

“经过与客户沟通，将神策数据的域名添加到白名单后，问题得以解决。”

[Aoang]

简单的总结一下，两个问题。

第一个问题，https 访问时，服务端未返回中间证书。
第二个问题，客户端劫持 https 。



倒不如深入讲讲 Let’s Encrypt 最开始的交叉签名…

CA 机构是有审计的，系统及游览器都会维护自己内置的根证书。
可以去讲讲 CA 机构是如何保障私钥安全的。还有 OSCP CT 都可以讲。

所谓安全，只要不透明，那里还能谈论安全…

[felix021]

@imes 随便写点东西，顺便想推啥推啥

[FrankAdler]

神策是大小周，大家慎重

[crazytec]

> 但是这里隐藏了一个大 bug：我们凭什么相信本地这些证书颁发机构是可信的？

了解一下 HPKP, OCSP stamping, DNS CAA?

后半截文章有点民科那味了

[felix021]

@FrankAdler 去年 8 月已经取消大小周了。

[felix021]

@crazytec 这些都是加强安全等级的手段，并不是 100%安全的保障。

btw ，是「 OCSP stapling 」，不是「 stamping 」。

[felix021]

@yuzo555 典型的「滑坡谬误」。我写的东西简单，不代表我司的技术水平差，更不代表技术水平差的公司就可以摸鱼。

[learningman]

建议顺便发到 CSDN 上，能帮到不少人

[felix021]

我认为嘲笑 /讽刺他人写的东西简单是不合适的：

1. 每个人都有自己的成长阶段，而「分享」本身就是值得鼓励的；
2. 写的内容简单不代表作者水平低；实际上很多人并不具备把简单的事情写清楚的能力；
3. 所谓曲高和寡，往往是简单的东西能帮助到更多的人；

另，如果认为我在文章里「推销」公司、公众号或者其他东西违反了社区规范，建议直接 @ Livid ，让他根据判断是否要删帖、封禁就好了。

其他不友好的行为反倒是反映了个人思维和行为的不成熟。

不过也没啥，之前也发过几篇，感受到 v2 并不算是很友好的社区，不过讨论技术问题，甚至连诅咒都有的，我也是挺意外的。

[felix021]

@learningman 有的，我的 csdn 会自动同步我的公众号

[des]

虽然但是，如果大家想要了解的话，我建议去 step-ca 的博客看，他们写的比较详细点

[imn1]

@felix021 #18
人家嘲笑的不是“分享”，而是“乱分享”，因为你没有遵守 V2EX 的规则
带引导的“分享”需要发到“推广”节点，这是 V2EX 大家接受的方式

[felix021]

@imn1 我没有注意到有这个规则，还是说是 v2 不成文的共识？之前发过很多次类似的文章，并没有得到类似的反馈。

如果要按社区规范的话「嘲讽」本身就是违规的，参见： https://v2ex.com/help/assertive

[ryd994]

我怎么觉得楼主是来反串黑的？
1. 技术水平拉跨，中级证书和根证书傻傻分不清楚。中级证书不是给你加到 CA 储存里用的。
2. 安全意识薄弱：PaaS 平台，客户给什么 CA 你就敢往平台上加？且不说中级证书的问题。就算客户需要自签 CA ，为什么不给让客户自己在应用里带上 CA bundle ，然后允许客户自定义 curl 库所用的 CA ？
你就不怕有恶意用户或者客户 CA 泄漏，然后你们自己的平台管理被黑？
3. 同样安全意识薄弱：让用户加白名单。当然这事算是小巫见大巫。我还见过很多银行和金融机构让客户加白名单的。但是错误的做法就是错误的。找个机会修掉，把技术债还一下也就算了。还要拿出来讲？
4. 你知道 wosign 的牌子是怎么臭掉的吗？因为 oscp 发现它未经允许签了一张证书。就算是内部测试，这也是不可接受的。各大浏览器直接把它的 CA 踢掉。
正规 CA 签发证书不是你自己电脑装个 OpenSSL 就想签什么签什么。人家是用专用的密码机。要是这层保护破了，那这家公司直接就没了。而建立一家新 CA 需要先挂靠在已有的 CA 下面，建立起相应的信用之后，各大浏览器才会把它加到 ca-bundle 里。
5. 不信任系统 CA 情有可原。cert pinning 了解一下？但是话又说回来，只有管理员权限才能导入 CA ，如果管理员权限本身不可信，这个问题已经超出了 TLS 的安全模型以外。因为 TLS 保护的传输过程，但保护不了本地不可信的客户端。我要有管理员权限我都随便看你内存了，还搞什么 CA ？

大家不要把安全相关的问题当成是编程问题。安全领域和编程隔着山呢。安全相关的内容留给专业人士去讲。

[ryd994]

* 4 不是 oscp 是证书透明度日志

[imn1]

@felix021 #22
站长开这个推广节点，自然有公告过相关规定

来这个站点的人，一般都不愿意浪费时间在基础知识上面，包括分享和咨询，并不是说人人都是万事通，但大部分人自学能力都过得去，基础知识都默认自行解决

而且你也看到站点的编辑界面设计，并不适合发表长文，这里更适合“提点”方式问答，而不是手把手教导，站长也规定了不允许全文转载，除非是自有版权的文章，方方面面都体现出和其他论坛不同，自行斟酌吧

[felix021]

@ryd994
3. 针对白名单做个解释，是客户内网做了劫持，加入的是「外网访问和劫持白名单列表」，这样才可以正确访问神策的 API 。

[felix021]

@ryd994
针对 2 也补充说明一下，并不是客户给的就直接加了，文中只是说明了方法（所以需要创建空的 keyStore 用来做验证），实际更新 ca-bundle 是运维同学的事情。

[felix021]

@ryd994
1. 之前只知道两个概念不同，确实没有仔细了解过二者的区别。中间证书应当部署在服务器上用来构建完整的信任链（减少浏览器下载的耗时和不可靠等问题），感谢你的回复。

[HackerJax]

TL;DR
1. 证书是证书签发机构签发的
2. 证书不被程序信任是因为根证书不被程序信任
3. 客户的环境非常严格，需将域名加入白名单才可访问

[phithon]

总结了一下楼上提到的版规：

1. v 站不适合发长文
2. v 站不适合发基础知识
3. 文章不能包含公众号链接、二维码等推广信息，否则需要发到推广板块

以前我还没注意。

[whitehack]

[felix021]

@phithon 还有「好好说话」 [狗头]

[felix021]

@whitehack 我写的时候就觉得这些 CA 机构大概会当打手，不过签假证书这种彻底自砸招牌的事情应该不至于。看来国内 CA 机构的业务量要好好涨一波了。

[felix021]

@imn1 特地去看了下「推广」节点，恐怕和你的理解是不一致的。包括「不适合发表长文」，这也是你的理解，我发过好多篇长文，有些文章还是得到了很多 v2 网友的肯定的，也请自行斟酌吧。

[gefranks]

如果有实际部署过证书, 或者做过 ssl offloading 的经验, 或者自己做过 MITM 的话,上面的错基本上看一下都知道是什么解决方案了.
至于公司劫持 SSL 的,工作的地方也有 WIP, 后来发现是根据进程名来的, chrome.exe 就会劫持,改成 c.exe 就不会劫持了.

[felix021]

@gefranks 是的，确实是比较浅显的东西，原意是记录一些实操的步骤备查（尤其我之前没搞过 java ），顺便用一些基础知识把逻辑串起来，写成一篇文章

[3dwelcome]

二维码在我手机上错位显示，完全没办法扫描。

[felix021]

@3dwelcome sorry 一直没注意手机上的情况，感兴趣的话可以搜公众号 felix021

[diegozhu]

😏😏我现在就在做一个项目，其中点对点通信部分远期方案就准备搞基于区块链的公钥来代替 ca 。

[hxndg]

tls 工程师表示写的东西太多了，有点杂，
直接针对 curl 的错误提示继续分析就行了：“curl: (60) Peer's Certificate issuer is not recognized.”
你这个写的东西吧，初学者看的话容易乱，从业者又觉得真能水。。。凝练写比较好


@ryd994 证书钉扎？还是公钥钉扎？我记得公钥钉扎现在没啥人用了吧？


@phithon 就没有不适合发长文，发基础知识的规定。C++板里面一堆基础知识，也没谁说不好。

[felix021]

@hxndg 是的，确实写得有点碎，前面说了，主要是记录自己的一些操作备查，加上一些觉得可能有用的基础知识串起来。

「不适合发长文、基础知识」是 25 楼的观点，我怀疑 30 楼这位同学可能是在说反话~

[shanliang]

这什么客户用沃通的证书，不是来搞笑的吗

[felix021]

@shanliang 客户用的不是 wosign ，我在原文没有提到；只是 23 楼提了 wosign 的一个 bad case 。

[ryd994]

@felix021 #27 这依然不可以接受。除非你们有专业人士能复制审核要加入的中级证书。中级证书不需要加到 CA 列表，只有 CA 才能加。楼上已经说过了，是对方服务器没有正确配置 chaining ，正常情况下是服务器会把除了 CA 的两个证书都发过来。
你的服务器的安全运作全都可能依赖 ca-bundle （虽然 Linux 通常还有 gpg 签名，但问题是你不知道还有什么别的程序也用到了）

这不是一个运维问题，这是一个安全问题，影响的不仅仅是这个客户，还有你平台的安全和其他客户的安全。。

解决办法我也说过了，给客户请求单独指定 ca 文件，不可以动操作系统的 CA 。

[ryd994]

浏览器获取中级证书不需要额外花费时间，是服务器在 TLS 握手时，应该发来证书链上除了 CA 的所有证书。CA 不需要因为 CA 发了也没用。
@whitehack #31 这些也是商业公司。可以选择不和任何人做生意也不给任何人提供服务。但是，这不能成为楼主说的签发假证书的理由。

中国有 wosign 啊，那事后来也就被 ban 了一年。wosign 的资质还是在的。但是这事无论你有没有 CA 你都一样完蛋了。
除了 CA 还要有证书透明度服务。这也是西方的哦。
也就是说你唯一选择就是自建全套服务。原理上来说并不难。实际操作上嘛，非常时间非常手段，审计跳过就好了。反正都是要改配置（就算不改 CA 也要禁用透明度要求）。放飞自我以后自签也不是什么问题嘛。你看 12306 还不是用自签用了很久。

[kingfalse]

直接忽略证书校验就可以，不必要水出这么大一片水文，真的

[kingfalse]

@felix021 分享了个广告？

[Livid]

@maleclub 谢谢。这个主题已经被移动到 /go/promotions

[ihciah]

楼主不是字节的吗？

[felix021]

@ihciah 换了大半年了

[shenqi]

将一句话的事情写成一篇文章，专家啊。

[felix021]

@kingfalse 我这写了半天还被喷技术差，您这句话要是让楼上几位看见了，估计更惨

[kevinlexming]

一石三鸟

[libotony]

这个问题好像是某个 CA 的根证书过期了，浏览器或者操作系统在更新中把新的 CA 证书给加进去了并且做了重定向，但是 curl 或者某些编程语言所依赖的证书库并没有更新，直接信任 CA 是一个非常粗暴的解决方案。正确的方式是找到根本原因，本例中应该交叉对比 openssl 获取的证书链和浏览器的证书链是不是一致，不然别人去请求你的客户的 AP I 还会出错。如果猜的没错的话，证书更新一下就好了。

[xloger]

楼主我倒是关注挺久了，大部分帖子内容都看过且比较有意思。而且招人部分每次都会被说......
这之间的界限不好区分，但对我来说能接受。

[Immortal]

看到 id 才发现是 rss 订阅里的老哥 之前写的文章挺有趣