V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
felix021
V2EX  ›  推广

一张证书引发的噱案

  •  
  •   felix021 · 2022-03-13 16:41:52 +08:00 · 7930 次点击
    这是一个创建于 824 天前的主题,其中的信息可能已经有所发展或是发生改变。

    - 引 -

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

    - 起 -

    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 并投递简历。

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

       ▄▄▄▄▄▄▄   ▄      ▄▄▄▄ ▄▄▄▄▄▄▄  
       █ ▄▄▄ █ ▄▀ ▄ ▀██▄ ▀█▄ █ ▄▄▄ █  
       █ ███ █  █  █  █▀▀▀█▀ █ ███ █  
       █▄▄▄▄▄█ ▄ █▀█ █▀█ ▄▀█ █▄▄▄▄▄█  
       ▄▄▄ ▄▄▄▄█  ▀▄█▀▀▀█ ▄█▄▄   ▄    
       ▄█▄▄▄▄▄▀▄▀▄██   ▀ ▄  █▀▄▄▀▄▄█  
       █ █▀▄▀▄▄▀▀█▄▀█▄▀█████▀█▀▀█ █▄  
        ▀▀  █▄██▄█▀  █ ▀█▀ ▀█▀ ▄▀▀▄█  
       █▀ ▀ ▄▄▄▄▄▄▀▄██  █ ▄████▀▀ █▄  
       ▄▀▄▄▄ ▄ ▀▀▄████▀█▀  ▀ █▄▄▄▀▄█  
       ▄▀▀██▄▄  █▀▄▀█▀▀ █▀ ▄▄▄██▀ ▀   
       ▄▄▄▄▄▄▄ █ █▀ ▀▀   ▄██ ▄ █▄▀██  
       █ ▄▄▄ █ █▄ ▀▄▀ ▀██  █▄▄▄█▄  ▀  
       █ ███ █ ▄ ███▀▀▀█▄ █▀▄ ██▄ ▀█  
       █▄▄▄▄▄█ ██ ▄█▀█  █ ▀██▄▄▄  █▄  
    
    56 条回复    2022-03-14 15:20:54 +08:00
    imes
        1
    imes  
       2022-03-13 17:00:58 +08:00 via Android   ❤️ 24
    你到底是推销 github 项目?还是招聘广告?还是公众号推广?我现在思路有点乱,反应不过来。
    maleclub
        2
    maleclub  
       2022-03-13 17:12:42 +08:00 via Android
    maleclub
        3
    maleclub  
       2022-03-13 17:14:13 +08:00 via Android   ❤️ 1
    oneisall8955
        4
    oneisall8955  
       2022-03-13 17:14:42 +08:00 via Android
    @maleclub livi🐶
    yuzo555
        5
    yuzo555  
       2022-03-13 17:17:14 +08:00   ❤️ 9
    一个 CA 证书都能水一篇文的公司,技术水平大家可以掂量下,一定很适合摸鱼,各位羊毛摸鱼党不要错过
    yuzo555
        6
    yuzo555  
       2022-03-13 17:18:52 +08:00   ❤️ 1
    原来是内推不是直招,那可能是按人头计费的,收回 #5 的话,不能便宜楼主了
    choury
        7
    choury  
       2022-03-13 17:19:18 +08:00 via Android
    你们为什么不像百度一样,让服务器把中间证书也发过来?
    jiuhuicinv
        8
    jiuhuicinv  
       2022-03-13 17:21:04 +08:00
    看不懂
    felixcode
        9
    felixcode  
       2022-03-13 17:29:46 +08:00 via Android   ❤️ 5
    “经过与客户沟通,将神策数据的域名添加到白名单后,问题得以解决。”
    Aoang
        10
    Aoang  
       2022-03-13 17:44:34 +08:00 via iPhone   ❤️ 1
    简单的总结一下,两个问题。

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



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

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

    所谓安全,只要不透明,那里还能谈论安全…
    felix021
        11
    felix021  
    OP
       2022-03-13 17:46:24 +08:00
    @imes 随便写点东西,顺便想推啥推啥
    FrankAdler
        12
    FrankAdler  
       2022-03-13 17:46:42 +08:00 via iPhone   ❤️ 1
    神策是大小周,大家慎重
    crazytec
        13
    crazytec  
       2022-03-13 17:50:26 +08:00
    > 但是这里隐藏了一个大 bug:我们凭什么相信本地这些证书颁发机构是可信的?

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

    后半截文章有点民科那味了
    felix021
        14
    felix021  
    OP
       2022-03-13 17:50:42 +08:00
    @FrankAdler 去年 8 月已经取消大小周了。
    felix021
        15
    felix021  
    OP
       2022-03-13 17:58:12 +08:00
    @crazytec 这些都是加强安全等级的手段,并不是 100%安全的保障。

    btw ,是「 OCSP stapling 」,不是「 stamping 」。
    felix021
        16
    felix021  
    OP
       2022-03-13 18:03:21 +08:00   ❤️ 1
    @yuzo555 典型的「滑坡谬误」。我写的东西简单,不代表我司的技术水平差,更不代表技术水平差的公司就可以摸鱼。
    learningman
        17
    learningman  
       2022-03-13 18:06:12 +08:00
    建议顺便发到 CSDN 上,能帮到不少人
    felix021
        18
    felix021  
    OP
       2022-03-13 18:13:28 +08:00   ❤️ 22
    我认为嘲笑 /讽刺他人写的东西简单是不合适的:

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

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

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

    不过也没啥,之前也发过几篇,感受到 v2 并不算是很友好的社区,不过讨论技术问题,甚至连诅咒都有的,我也是挺意外的。
    felix021
        19
    felix021  
    OP
       2022-03-13 18:13:51 +08:00
    @learningman 有的,我的 csdn 会自动同步我的公众号
    des
        20
    des  
       2022-03-13 18:17:17 +08:00 via iPhone
    虽然但是,如果大家想要了解的话,我建议去 step-ca 的博客看,他们写的比较详细点
    imn1
        21
    imn1  
       2022-03-13 18:22:04 +08:00   ❤️ 1
    @felix021 #18
    人家嘲笑的不是“分享”,而是“乱分享”,因为你没有遵守 V2EX 的规则
    带引导的“分享”需要发到“推广”节点,这是 V2EX 大家接受的方式
    felix021
        22
    felix021  
    OP
       2022-03-13 18:27:50 +08:00   ❤️ 1
    @imn1 我没有注意到有这个规则,还是说是 v2 不成文的共识?之前发过很多次类似的文章,并没有得到类似的反馈。

    如果要按社区规范的话「嘲讽」本身就是违规的,参见: https://v2ex.com/help/assertive
    ryd994
        23
    ryd994  
       2022-03-13 18:37:59 +08:00 via Android   ❤️ 27
    我怎么觉得楼主是来反串黑的?
    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
        24
    ryd994  
       2022-03-13 18:43:10 +08:00 via Android
    * 4 不是 oscp 是证书透明度日志
    imn1
        25
    imn1  
       2022-03-13 18:46:41 +08:00
    @felix021 #22
    站长开这个推广节点,自然有公告过相关规定

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

    而且你也看到站点的编辑界面设计,并不适合发表长文,这里更适合“提点”方式问答,而不是手把手教导,站长也规定了不允许全文转载,除非是自有版权的文章,方方面面都体现出和其他论坛不同,自行斟酌吧
    felix021
        26
    felix021  
    OP
       2022-03-13 18:49:54 +08:00
    @ryd994
    3. 针对白名单做个解释,是客户内网做了劫持,加入的是「外网访问和劫持白名单列表」,这样才可以正确访问神策的 API 。
    felix021
        27
    felix021  
    OP
       2022-03-13 19:01:56 +08:00
    @ryd994
    针对 2 也补充说明一下,并不是客户给的就直接加了,文中只是说明了方法(所以需要创建空的 keyStore 用来做验证),实际更新 ca-bundle 是运维同学的事情。
    felix021
        28
    felix021  
    OP
       2022-03-13 19:12:53 +08:00
    @ryd994
    1. 之前只知道两个概念不同,确实没有仔细了解过二者的区别。中间证书应当部署在服务器上用来构建完整的信任链(减少浏览器下载的耗时和不可靠等问题),感谢你的回复。
    HackerJax
        29
    HackerJax  
       2022-03-13 19:46:07 +08:00 via iPhone
    TL;DR
    1. 证书是证书签发机构签发的
    2. 证书不被程序信任是因为根证书不被程序信任
    3. 客户的环境非常严格,需将域名加入白名单才可访问
    phithon
        30
    phithon  
       2022-03-13 19:48:39 +08:00   ❤️ 1
    总结了一下楼上提到的版规:

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

    以前我还没注意。
    whitehack
        31
    whitehack  
       2022-03-13 20:08:30 +08:00   ❤️ 2
    felix021
        32
    felix021  
    OP
       2022-03-13 20:37:02 +08:00
    @phithon 还有「好好说话」 [狗头]
    felix021
        33
    felix021  
    OP
       2022-03-13 20:38:34 +08:00
    @whitehack 我写的时候就觉得这些 CA 机构大概会当打手,不过签假证书这种彻底自砸招牌的事情应该不至于。看来国内 CA 机构的业务量要好好涨一波了。
    felix021
        34
    felix021  
    OP
       2022-03-13 20:41:56 +08:00
    @imn1 特地去看了下「推广」节点,恐怕和你的理解是不一致的。包括「不适合发表长文」,这也是你的理解,我发过好多篇长文,有些文章还是得到了很多 v2 网友的肯定的,也请自行斟酌吧。
    gefranks
        35
    gefranks  
       2022-03-13 21:23:03 +08:00
    如果有实际部署过证书, 或者做过 ssl offloading 的经验, 或者自己做过 MITM 的话,上面的错基本上看一下都知道是什么解决方案了.
    至于公司劫持 SSL 的,工作的地方也有 WIP, 后来发现是根据进程名来的, chrome.exe 就会劫持,改成 c.exe 就不会劫持了.
    felix021
        36
    felix021  
    OP
       2022-03-13 21:29:08 +08:00
    @gefranks 是的,确实是比较浅显的东西,原意是记录一些实操的步骤备查(尤其我之前没搞过 java ),顺便用一些基础知识把逻辑串起来,写成一篇文章
    3dwelcome
        37
    3dwelcome  
       2022-03-13 22:48:12 +08:00
    二维码在我手机上错位显示,完全没办法扫描。
    felix021
        38
    felix021  
    OP
       2022-03-13 22:58:17 +08:00
    @3dwelcome sorry 一直没注意手机上的情况,感兴趣的话可以搜公众号 felix021
    diegozhu
        39
    diegozhu  
       2022-03-13 22:58:41 +08:00 via Android
    😏😏我现在就在做一个项目,其中点对点通信部分远期方案就准备搞基于区块链的公钥来代替 ca 。
    hxndg
        40
    hxndg  
       2022-03-13 23:01:45 +08:00   ❤️ 1
    tls 工程师表示写的东西太多了,有点杂,
    直接针对 curl 的错误提示继续分析就行了:“curl: (60) Peer's Certificate issuer is not recognized.”
    你这个写的东西吧,初学者看的话容易乱,从业者又觉得真能水。。。凝练写比较好


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


    @phithon 就没有不适合发长文,发基础知识的规定。C++板里面一堆基础知识,也没谁说不好。
    felix021
        41
    felix021  
    OP
       2022-03-13 23:07:32 +08:00
    @hxndg 是的,确实写得有点碎,前面说了,主要是记录自己的一些操作备查,加上一些觉得可能有用的基础知识串起来。

    「不适合发长文、基础知识」是 25 楼的观点,我怀疑 30 楼这位同学可能是在说反话~
    shanliang
        42
    shanliang  
       2022-03-13 23:58:39 +08:00 via iPad
    这什么客户用沃通的证书,不是来搞笑的吗
    felix021
        43
    felix021  
    OP
       2022-03-14 00:42:25 +08:00
    @shanliang 客户用的不是 wosign ,我在原文没有提到;只是 23 楼提了 wosign 的一个 bad case 。
    ryd994
        44
    ryd994  
       2022-03-14 02:28:04 +08:00 via Android
    @felix021 #27 这依然不可以接受。除非你们有专业人士能复制审核要加入的中级证书。中级证书不需要加到 CA 列表,只有 CA 才能加。楼上已经说过了,是对方服务器没有正确配置 chaining ,正常情况下是服务器会把除了 CA 的两个证书都发过来。
    你的服务器的安全运作全都可能依赖 ca-bundle (虽然 Linux 通常还有 gpg 签名,但问题是你不知道还有什么别的程序也用到了)

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

    解决办法我也说过了,给客户请求单独指定 ca 文件,不可以动操作系统的 CA 。
    ryd994
        45
    ryd994  
       2022-03-14 02:42:33 +08:00 via Android
    浏览器获取中级证书不需要额外花费时间,是服务器在 TLS 握手时,应该发来证书链上除了 CA 的所有证书。CA 不需要因为 CA 发了也没用。
    @whitehack #31 这些也是商业公司。可以选择不和任何人做生意也不给任何人提供服务。但是,这不能成为楼主说的签发假证书的理由。

    中国有 wosign 啊,那事后来也就被 ban 了一年。wosign 的资质还是在的。但是这事无论你有没有 CA 你都一样完蛋了。
    除了 CA 还要有证书透明度服务。这也是西方的哦。
    也就是说你唯一选择就是自建全套服务。原理上来说并不难。实际操作上嘛,非常时间非常手段,审计跳过就好了。反正都是要改配置(就算不改 CA 也要禁用透明度要求)。放飞自我以后自签也不是什么问题嘛。你看 12306 还不是用自签用了很久。
    kingfalse
        46
    kingfalse  
       2022-03-14 08:12:51 +08:00 via Android
    直接忽略证书校验就可以,不必要水出这么大一片水文,真的
    kingfalse
        47
    kingfalse  
       2022-03-14 08:20:29 +08:00 via Android
    @felix021 分享了个广告?
    Livid
        48
    Livid  
    MOD
       2022-03-14 10:06:01 +08:00   ❤️ 1
    @maleclub 谢谢。这个主题已经被移动到 /go/promotions
    ihciah
        49
    ihciah  
       2022-03-14 10:15:21 +08:00 via iPhone
    楼主不是字节的吗?
    felix021
        50
    felix021  
    OP
       2022-03-14 10:35:44 +08:00
    @ihciah 换了大半年了
    shenqi
        51
    shenqi  
       2022-03-14 10:37:49 +08:00
    将一句话的事情写成一篇文章,专家啊。
    felix021
        52
    felix021  
    OP
       2022-03-14 10:38:08 +08:00
    @kingfalse 我这写了半天还被喷技术差,您这句话要是让楼上几位看见了,估计更惨
    kevinlexming
        53
    kevinlexming  
       2022-03-14 11:27:08 +08:00
    一石三鸟
    libotony
        54
    libotony  
       2022-03-14 12:08:38 +08:00
    这个问题好像是某个 CA 的根证书过期了,浏览器或者操作系统在更新中把新的 CA 证书给加进去了并且做了重定向,但是 curl 或者某些编程语言所依赖的证书库并没有更新,直接信任 CA 是一个非常粗暴的解决方案。正确的方式是找到根本原因,本例中应该交叉对比 openssl 获取的证书链和浏览器的证书链是不是一致,不然别人去请求你的客户的 AP I 还会出错。如果猜的没错的话,证书更新一下就好了。
    xloger
        55
    xloger  
       2022-03-14 13:17:58 +08:00
    楼主我倒是关注挺久了,大部分帖子内容都看过且比较有意思。而且招人部分每次都会被说......
    这之间的界限不好区分,但对我来说能接受。
    Immortal
        56
    Immortal  
       2022-03-14 15:20:54 +08:00
    看到 id 才发现是 rss 订阅里的老哥 之前写的文章挺有趣
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4741 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 09:42 · PVG 17:42 · LAX 02:42 · JFK 05:42
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.