介绍数字证书中的两种异常情况。
访问accbilletengineering.co.za产生的数据包如图1
访问360travel.co.za产生的数据包如图2
可以看出两次所抓的数据包中对应的网站证书的CN 为 .aserv.co.za,在其使用者备用名称属性中也是.aserv.co.za。正常情况下(SSL加速情况由于加密通常存在于CDN缓存服务器和用户之间,使用的证书为CDN提供的证书,因此其CN可能会不一样),在为网站申请证书的时候CN为其网站的名称。而此处不一致的原因是上述两个网站复用了该网站证书(可能是节约成本,也可能是其他原因)。在证书链传递到浏览器端的时候,浏览器解析CN和访问的网站名称不一致,会提示告警,当手动点击继续的时候,能继续访问。
上述两次访问的网站证书均为1198个字节,取这两个证书的md5值是相同的,因此这两个证书的内容完全相同。但是对这两个证书链整体取md5后发现,其md5值是不相同的。究其原因,通过上面两幅图也可以发现,图1和图2中间证书的位置有所颠倒。
证书链的第一级,网站证书展示的证书issuer是RapidSSL,如图3,图1的证书链的第二级中间证书,其subject正好是RapidSSL,而图2则不是。因此证书链的正常过程应该是如图1所示的情况。事实上图2虽然中级证书和根证书的顺序有所颠倒,但是在浏览器端还是能够正常解析的。
这就涉及到证书链的验证过程,我理解的证书链的一种验证过程如下:
Server向client传输一串证书链,证书链验证该网站证书是否合法的依据是一级一级的查找该证书的颁发者,使用颁发者的公钥验证签名,直至找到颁发者为系统内置的根证书为止。如果整个证书链的验证是合法的,则该证书是合法的,反之则非法。
从这里面可以看出,无论自上向下还是自下而上的方式,通过issuer或者subject来寻找下一级的证书,在用户证书确定的情况下,与实际过程中证书链的传输顺序是无关的。
图4是图1中证书链的最后一个,可以看到issuer为Equifax,这是一个浏览器内置的根证书。
图5是chrome浏览器解析证书的情况,可以看到最后证书链的根并不是Equifax,而是GeoTrust Global CA,这是因为GeoTrust Global CA也是系统内置的根证书,浏览器在解析证书链的时候,到达第二级证书的时候,如图6,由于第二级证书的issuer为GeoTrust Global CA,这时候正好匹配浏览器内置的根证书。因此图1中最后一个证书也就没有意义,不会去验证了。同理,图2中实际上也只是验证了证书链中第一个和第三个证书。
为什么会出现上述情况呢,Equifax曾经是被GeoTrust收购的,可能是一些产品线的调整所导致的吧。
Ps:因为图2出现感觉是网站配置人员在配置证书的时候出现了失误。
另外,当整个证书链传输的过程中如果出现丢包的情况,也是会导致整个证书链md5不一致,证书链的一部分值md5相同的情况。
本文为CSDN村中少年原创文章,转载记得加上小尾巴偶,博主链接 这里。