分享

CFCA SSL证书踩坑记

 ynhnzp 2019-10-12

欢迎访问陈同学博客原文

本文分享CFCA SSL证书的小坑,简介CFCA SSL后将以一个小例子介绍httpclient使用过程中的证书问题,最后介绍证书问题的处理方式。

CFCA SSL简介

CFCA 指中国金融认证中心,也是国家级的权威安全认证机构,服务于国内银行、保险、证券等金融企业。官方资料显示:

  • CFCA 是国际CA浏览器联盟组织成员,是国际证书标准的参与者

  • 根证书已存在于微软系统、Mozilla相关产品、安卓系统以及苹果相关产品中。

这确实很厉害,回想早几年12306使用自签名证书,用户访问时需要确认,目前12306也切换到 digicert 颁发的证书。

再来看看CFCA的,其根证书已存在于操作系统信任库中(有的浏览器使用自有证书库,如Firefox;有的直接使用OS的信任库,但存在白名单)。

目前CFCA的SSL证书在百度云有售,阿里云、腾讯云、华为云卖的主要还是Symantec、GeoTrust、Globalsign等国际权威公司的。

看着一切都挺好的,还能踩什么坑呢?

踩坑记

因合作关系,CFCA 送了张2年的SSL证书,按百度售价也是价值3W,正好产品SSL证书快到期,于是在测试环境尝试使用。

使用时先是我本机浏览器显示不安全,接着有第三方集成公司反馈测试系统SSL通讯出现证书问题。看了CFCA资料后才发现:

CFCA 根证书 2016.10.25 随着苹果IOS 10.1、Mac OS 10.12.1发布才嵌入苹果根证书库,在此之前,其根证书已加入微软、Mozilla、安卓的根证书库。

自然,我15年的老电脑且系统未升级的人就中招了。

了解第三方集成公司后,他们使用的Java技术栈,那估计是CFCA根证书不在JDK默认的信任库中导致的。

下面分析下问题的原理及处理方式。

Httpclient SSL 通讯演示

阮一峰老师的 图解SSL/TLS协议 一文详细介绍了SSL通讯,这里用一段简短代码配合日志介绍Java中使用httpclient处理SSL通讯的几个步骤。

// 使用 org.apache.httpcomponents:httpclient:4.5.7
HttpClients.createDefault().execute(new HttpGet("https://www.baidu.com/"));

添加JVM参数 -Djavax.net.debug=all ,运行上述代码,可以看到整个SSL通讯的日志。

  • 启动时,程序使用的trustStore 是 $JAVA_HOME/jre/lib/security/cacerts,国际权威公司的根证书都内置在JDK及操作系统信任库中。

不清楚 Keystore 和 Truststore 可参考 Difference Between a Java Keystore and a Truststore

  • SSL通讯时,首先Client向Server打招呼,将自己的SSL/TLS版本(TLSv1.2)、支持的加密算法(Cipher)等信息发送过去

  • 接着,Server返回选择的加密算法以及自己的证书链。

有时Client使用TLSv1.1及以下版本,出于安全起见,Server端一般使用TLSv1.2及以上,会出现问题

证书链日志比较多,就直接在浏览器上看证书链。第一个是根证书颁发机构,第二个是中级证书颁发机构,第三个是颁发给百度的证书。Server端返回证书链的作用是证明 “我是百度”,因为ROOT CA下就一个百度,证书作不了假。

  • Client拿到Server的证书链后,会在TrustStore中查找证书。对于百度,找到了 GlobalSign Root CA 这个根证书,因此可以确认Server端确实是百度,不是其他钓鱼网站。

CFCA 根证书问题

可是JDK工具查看信任库的所有证书,确实没有CFCA的,检查了各JDK版本,JDK12也没有CFCA的根证书。

keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts

下面以访问CFCA官网为例来复现问题。

HttpClients.createDefault().execute(new HttpGet("https://www./"));

执行代码后会看到熟悉的找不到证书的错误,这是因为在信任库中找不到Server端返回的证书链中的任何证书,无法判断服务端到底是谁,因此拒绝连接,关闭了socket。

下面是Server返回的证书链中的三个证书subject信息,由于CFCA根证书不在JDK信任库中,我们自己也可以伪造一模一样的证书出来,如果能劫持DNS,那Client就被钓鱼了,连接了个假服务端,然后把数据都发过去了。

Subject: CN=www., OU=运行部, O=中金金融认证中心有限公司
Subject: CN=CFCA EV OCA, O=China Financial Certification Authority, C=CN
Subject: CN=CFCA EV ROOT, O=China Financial Certification Authority, C=CN

如何处理证书问题

那针对这种证书怎么处理比较好呢?按照优劣程度,我排了序:

  • 最佳方式:不使用CFCA的SSL证书,推荐使用国际顶级CA公司颁发的证书,他们的根证书都内置在各种OS、浏览器及JDK的证书库中。

  • 次优选择:如果由于其他因素非得使用一般的证书,则直接导入根证书。例如将CFCA的根证书导入JDK,但这需要合作伙伴做导入操作,如果合作伙伴比较多将非常麻烦。导入根证书的好处:根证书有效期长达二十甚至三十年,购买的证书往往只有几年,后续证书升级后不用重复导入证书到信任库

  • 较差选择:导入自己购买的证书,到期升级后需要通知第三方合作伙伴升级信任库中证书,十分麻烦。

  • 最差选择:作为调用方,可以选择忽略证书验证,这样即使服务端证书不在自己的信任库中,也可以进行SSL通讯,便利的同时,也会带来巨大的安全风险,需要衡量。

综上,购买证书时要考虑自身使用及第三方集成伙伴的情况,尽量选择根证书内置在各OS、浏览器及各程序语言单独信任库的机构颁发的证书。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多