1. 背景
某TIC网站提供O2O服务，客户在线下单并点击在线支付，会跳转到支付宝收银台进行付款，付款成功完成后，支付宝会调用TIC网站接口，通知TIC网站付款成功。
2. 问题现象
测试中，发现支付成功完成后，TIC网站并没有收到支付宝的回调通知。经过排查后发现，该TIC网站的ssl证书链并不完整。
在线验证工具：https://cryptoreport.websecurity.symantec.com/checker/
另一个工具：https://www.ssllabs.com/ssltest/
工具三：https://ssltools.digicert.com/checker/
3. 解决思路分析
由以上监测工具可知，ssl证书具体的问题为：Missing Intermediate Certificates
GoDaddy 对 Intermediate Certificates的解释：https://sg.godaddy.com/zh/help/what-is-an-intermediate-certificate-868
4. 证书链原理
浏览器的安装包里，保存着一些它信任的根证书（公钥）。
证书发行商们为了安全，通常会将这些根证书对应的私钥保存在绝对断网的金库里。在金库里用这些根私钥，签发一些“中级”证书，这些中级证书的私钥拥有签发再下一级证书的权限。这些中级私钥被安装到在线服务器上，通过签发网站证书来赚钱。一旦这些服务器被黑，发行商就可以利用金库里物理隔离的根证书私钥，可以签发吊销令，消灭这些中级证书的信任，而不必让各家浏览器彻底不信任这家发行商的根证书。再签一条新的中级发行证书，又是一条能赚钱的好汉。
问题来了。
浏览器只认根证书。中级证书的认证，你（网站）得自己开证明。
一个正确配置的HTTPS网站应该在证书中包含完整的证书链。
比如以 openssl s_client -connect www.wosign.com:443 命令来查看wosign自己的网站配置。
其余内容可以无视，只看Certificate chain这一段：
—
Certificate chain
0 s:/1.3.6.1.4.1.311.60.2.1.3=CN/1.3.6.1.4.1.311.60.2.1.2=Guangdong/1.3.6.1.4.1.311.60.2.1.1=Shenzhen/businessCategory=Private Organization/serialNumber=440301103308619/C=CN/ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/L=\xE6\xB7\xB1\xE5\x9C\xB3\xE5\xB8\x82/postalCode=518067/street=\xE6\xB7\xB1\xE5\x9C\xB3\xE5\xB8\x82\xE5\x8D\x97\xE5\xB1\xB1\xE5\x8C\xBA\xE5\x8D\x97\xE6\xB5\xB7\xE5\xA4\xA7\xE9\x81\x931057\xE5\x8F\xB7\xE7\xA7\x91\xE6\x8A\x80\xE5\xA4\xA7\xE5\x8E\xA6\xE4\xBA\x8C\xE6\x9C\x9FA\xE6\xA0\x8B502#/O=WoSign\xE6\xB2\x83\xE9\x80\x9A\xE7\x94\xB5\xE5\xAD\x90\xE8\xAE\xA4\xE8\xAF\x81\xE6\x9C\x8D\xE5\x8A\xA1\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8/CN=www.wosign.com
i:/C=CN/O=WoSign CA Limited/CN=WoSign Class 4 EV Server CA
1 s:/C=CN/O=WoSign CA Limited/CN=WoSign Class 4 EV Server CA
i:/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
2 s:/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
—
其中0、1、2是证书链中每一级证书的序号。0是要被验证的网站所用的证书。其CN应该对应网站域名。
每一个序号后面，s开头的一行是指证书，i开头的一行是指此证书由谁签发。
可以看出，0的CN包含一个疑似中文域名，加一个英文域名www.wosign.com。它的签发者是WoSign CA Limited/CN=WoSign Class 4 EV Server CA。
1的证书就是0的签发者。而1自己又是由另一个证书Certification Authority of WoSign签发的。
再看下一级，2。它说，Certification Authority of WoSign是由StartCom签发的（哈哈，原来是转包商！）
所以这么一级级看下来，浏览器说，哦，2的签发者我认识啊，安装包里有提到，StartCom嘛。签名正确、验证无误，所以信任2。那么也应该信任2签发的1、1签发的0。所以这个网站可以信任。
－－
然而，如果网站配置时，在crt文件中只包含了自己，而没包含一个完整到可以被浏览器内置数据验证的证书链，就有可能被浏览器拒绝。比如
openssl s_client -connect touko.moe:443
—
Certificate chain
0 s:/CN=touko.moe
i:/C=CN/O=WoSign CA Limited/CN=WoSign CA Free SSL Certificate G2
—
只有0一组。说明s行中的touko.moe由i行中的WoSign CA Free SSL Certificate G2签发。没了。
这就是此坑最神奇之处：浏览器此时是否验证失败，是不一定的。有2种情况：
A、浏览器自安装以来，从未见过这个i。那么验证会失败。
B、浏览器以前见过、并且验证过i，那么验证会成功。
通常管理员自己会去证书发行商的https网站买证书，浏览器就会验证，然后将验证成功的中间证书全都缓存下来，为以后节省时间。当管理员（错误地）配置完自己的网站，去浏览测试的时候，完全不会遇到问题。因为他的浏览器已经认识这个中间证书了。
但很多用户可能都没访问过其他正确配置的、由这家中级证书签发的网站。所以，验证会因为找不到能够信任的签发者而失败。
简直堪比大众柴油车的尾气排放控制。检查时一切正常。一到外面就放毒。
5. 解法
原本的想法是用搜索到的工具SSLChainSaver (https://blogs.msdn.microsoft.com/windowsmobile/2006/08/11/introducing-the-sslchainsaver/, https://blogs.msdn.microsoft.com/windowsmobile/2008/05/18/sslchainsaver-v2-released/) 进行证书链补齐，但是该工具微软已不提供下载。
采用手动补齐证书链的方法，将证书链内容以下面格式放到一个文件中，以server.crt 命名：
-----BEGIN CERTIFICATE----- #Your SSL Certificate# -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- #Intermediate Certificate# -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- #Root Certificate# -----END CERTIFICATE-----
在nginx中将证书路径指向该 .crt 文件。
ssl_certificate /etc/ssl/your_domain.crt; ssl_certificate_key /etc/ssl/your_domain.key; 注意事项：如果是在Apache中，则还需要设置SSLCertificateChainFile参数，该文件路径指向上面同一个 .crt文件。
6. 结果
经测试，故障解决。
参考资料：
1)https://docs.microsoft.com/en-us/previous-versions/office/exchange-remote-connectivity/ee410524(v=exchg.80)
2)https://support.globalsign.com/customer/en/portal/articles/1290470-install-certificate—nginx
3)https://support.globalsign.com/customer/portal/articles/1426602-globalsign-root-certificates
4)https://blogs.msdn.microsoft.com/windowsmobile/2006/08/11/introducing-the-sslchainsaver/
5)https://sg.godaddy.com/zh/help/what-is-an-intermediate-certificate-868
6)https://blog.csdn.net/langyalaoa/article/details/66974561
7)https://www.itsvse.com/thread-3979-1-1.html