CFCA SSL 证书踩坑记

封面图片来源： https://www.nytimes.com/guides/well/how-to-start-running

本文分享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工具keytool查看信任库的所有证书，检查了各JDK版本，JDK12也没有CFCA的根证书。

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

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

HttpClients.createDefault()

.execute(new HttpGet("https://www.cfca.com.cn/"));

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

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

Subject: CN=www.cfca.com.cn, 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、浏览器及各程序语言单独信任库的机构颁发的证书。