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

一张证书引发的噱案

  •  
  •   felix021 · 270 天前 · 7018 次点击
    这是一个创建于 270 天前的主题,其中的信息可能已经有所发展或是发生改变。

    - 引 -

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

    - 起 -

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

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



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

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

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

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

    后半截文章有点民科那味了
    felix021
        14
    felix021  
    OP
       270 天前
    @FrankAdler 去年 8 月已经取消大小周了。
    felix021
        15
    felix021  
    OP
       270 天前
    @crazytec 这些都是加强安全等级的手段,并不是 100%安全的保障。

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

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

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

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

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

    如果要按社区规范的话「嘲讽」本身就是违规的,参见: https://v2ex.com/help/assertive
    ryd994
        23
    ryd994  
       270 天前 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  
       270 天前 via Android
    * 4 不是 oscp 是证书透明度日志
    imn1
        25
    imn1  
       270 天前
    @felix021 #22
    站长开这个推广节点,自然有公告过相关规定

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

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

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

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


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


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

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

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

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

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