[原创]支付宝支付成功通知故障调试一例

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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.