数字证书的一些重要概念解析

ningxueqin

　　今天继续介绍一下数字证书里一些重要的概念和知识点。

　　双证书

　　在实际应用中，证书颁发机构（CA）一般为用户颁发双证书，也就是为申请证书的用户同时颁发两张证书，并告知用户其中一张是用来加密，即加密证书，另一张用来签名，即签名证书。这两张证书的主要信息是一致的，如证书持有人，颁发机构，有效期等，但证书对应的密钥对和密钥用法不同。

　　我们可以通过查看证书——详细信息——密钥用法查看证书是加密证书还是签名证书。加密证书对应的密钥对用于数据的非对称加解密；签名证书对应的密钥对用于数据的数字签名及验证。

　　按理说，一对公私钥就可以完成加解密和数字签名，为什么要分成两对公私钥分别完成呢？这还是由密钥的使用用途决定的。密钥用于数字签名时，保证的是签名行为的不可否认性，因此私钥必须由签名者自己持有保存，如果私钥遗失，只要重新申请颁发即可，不会影响已完成数字签名的验证；而密钥用于数据加密时，保证的是数据的机密性，如果私钥遗失，则已经加密的数据无法解密，因此必须有机制将私钥保存备份在第三方（如CA），以备私钥遗失情况下数据仍能解密。由此可见，签名和加密对密钥的保存备份要求是不一样的。所以合理的做法是将用于签名和加密的密钥分开，并采用不同的管理保存策略，已达到安全性和可用性的平衡。

　　在Windows的Crypto/API体系中，加密证书也可以用于签名，但签名证书不能用于加密。

　　CRL

　　CRL是Certificate Revocation List的简称，即证书吊销列表。它是CA发布证书有效信息的一种机制。CA将它发布的，并且已吊销的证书添加在CRL里，同时定期对外发布CRL。应用系统拿到CRL后，在列表中寻找将要验证的证书，以确定证书是否已经被颁发机构吊销。这个过程看上去没什么问题，但在实际应用中是有不少坑。

　　第一是应用系统如何拿到CRL。一般情况下，CA在颁发证书时会将CRL地址写在证书里，通过查看证书——详细信息——CRL分发点，可以查看到相关信息。

　　如果应用系统在需要下载或更新CRL时访问不了这个CRL地址，不仅不能得到CRL，可能还会产生其他问题，比如Adobe Reader的程序卡死，失去响应。

　　第二是应用系统更新CRL的策略问题。在CRL中包含本次更新日期和下次更新日期两个字段，应用系统可由这两个日期信息确定当前拥有的CRL是否是最新的，进而决定是否下载更新。这样就不可避免的出现吊销延迟的问题，即当前证书在CA端已经吊销了，但由于CRL还未到更新的时候，应用系统仍使用本地当前CRL，会认为已经被吊销证书有效。而且CRL在实际使用中的更新策略更加复杂（至少在Windows中是这样），进一步加剧了吊销延迟的不确定性。

　　第三是随着时间的推移，证书吊销列表会越来越长，即CRL数据会越来越大。下载CRL消耗的带宽资源和时间也会水涨船高，这对应用系统的稳定性和用户使用体验都会产生不利影响。

　　CRL出现那个时代，网络还不是很发达，为了减少CA服务器的压力，故采用在线下载，离线使用的方式发布证书吊销情况。虽然出现了一些改良的CRL产生和分发方法，但总体来讲，CRL已经不适合现在的互联网应用环境，也无法满足对证书验证实时性的要求。