证书是如何打通信任链的?

  1. 云栖社区>
  2. 博客列表>
  3. 正文

证书是如何打通信任链的?

kryptosx 2016-05-27 23:44:07 浏览3499 评论0

摘要: HTTPS通过证书来验证远程服务器是否合法。这就带来一个问题,我们怎么知道这个证书是合法的呢?如果证书是假的,那岂不是落入圈套了么。 证书路径: 我们通常在查看证书的详细信息时,可以查看证书的路径。

HTTPS通过证书来验证远程服务器是否合法。这就带来一个问题,我们怎么知道这个证书是合法的呢?如果证书是假的,那岂不是落入圈套了么。

证书路径:

我们通常在查看证书的详细信息时,可以查看证书的路径。如下图:

证书路径

这是alipay的证书,可以看到,它由“Symantec Class 3 Secure Server CA – G4”颁发。而“Symantec Class 3 Secure Server CA – G4”的证书又是由“VeriSign Class 3 Public Primary Certification Authority – G5”颁发的。再上面没有证书了,因为“VeriSign Class 3 Public Primary Certification Authority – G5”是根证书。

相当于是A,B,C三个人,A信任B,B信任C。我因为信任A,所以我也信任C。证书也是这样一个信任关系。

证书管理中心——CA:

CA是certificate authority的缩写,证书授权者。就是颁发证书的机构。

只有根证书是颁发机构颁发给自己的,因为这是从无到有的过程,这是信任的起始点,一般都是绑在操作系统上的。目前大部分的CA都是由根证书颁发机构授予证书颁发资格(其实就是给了个高级版证书)。

比如上面的VeriSign就是一个根证书颁发机构。貌似Symantec购买了VerSign的签名业务,所以Symantec也来颁发证书了,应该是二级证书吧。这果断是个一本万利的购买。

其实CA签发证书,就是用它自己的私钥来对证书的公钥做数字签名。后面会说到。

因为它是用于颁发证书的机构,因此,这个机构是否可信十分重要。比如,CNNIC 这种恶心的机构,颁发假证书,目前Chrome和Firefox 已经宣布不再信任CNNIC的证书。

CA的作用:

  •  接收验证最终用户数字证书的申请。
  • 确定是否接受最终用户数字证书的申请-证书的审批。
  • 向申请者颁发、拒绝颁发数字证书-证书的发放。
  • 接收、处理最终用户的数字证书更新请求-证书的更新。
  • 接收最终用户数字证书的查询、撤销。
  • 产生和发布证书废止列表(CRL)。
  • 数字证书的归档。
  • 密钥归档。
  • 历史数据归档。

证书的关键技术——公钥加密技术:

证书中最核心的就是公钥密码技术了。因为证书其实就是一个公钥。因此,在讲信任链如何打通前,需要稍微提一下公钥密码学。当然,证书也需要HASH算法,广义上也算密码学算法吧。

公钥密码学又称非对称密码学,是使用一对公钥和私钥的密码学。即,加密和解密的钥匙不是同一把准确的说是一对公钥和私钥,二者有关联,但技术上难以破解这个关联。因此,我们通常公开一把钥匙,保密另一把钥匙。它能用于加密数字签名

比如A是公钥,B是私钥。c是明文,s是密文,e为加密算法,d为解密算法。那么:

1 e(c,A)=s  //加密
2 d(s,B)=c  //解密
3 d(s,A)!=c //无法直接逆运算

加密

目的:让这段文字变得看不懂。

做法:用公钥加密,私钥解密。

好处:相比于只有一把钥匙的加密算法,如果密钥泄露。密文也就会被破解。但是如果是公钥加密算法,公钥可以直接公开。只要保证私钥安全即可。因为即使知道加密的钥匙也无法破解加密后的密文。

我们验证远程服务器合法性就是利用这个。

数字签名:

目的:让签名者无法抵赖。

做法:和加密反过来,我们用私钥加密,公钥来解密。

原因:加密后的内容只能由匹配的公钥来解开。只要保证对应的私钥只有一把,而且安全,那么,这段加密后的内容肯定无法伪造,反过来,签名者也就无法抵赖了。验证这个加密也不需要使用私钥,所以很容易保证私钥的安全。

证书的通信链打通:

前面的东西,其实都是为了解释这个。。。

证书信任链的关键其实是数字签名。即,我如果使用我的公钥能解开你的数字签名,就说明你是可信的。这个数字签名就是由证书颁发者(CA),用它的私钥对证书的公钥做的数字签名。那么这个证书就能被信任CA的证书所信任。通常,证书会包含,公钥,公钥的指纹,签名,证书名,签发者,等等。。。

我们假设有证书:A,B。A是B的办法者的证书。假设A的私钥用pr-A表示。公钥用pu-A表示,用A加密的数字签名sig-A-内容,某个内容的散列为hash(xxx)。

B证书是A颁发的,那么B的证书中就会有使用A证书的私钥做的数字签名。因此,要验证B证书的合法性,就需要用A证书的公钥来解开。我们安装证书时,系统通常会自动验证合法性。比如安装B证书。(假设A证书已经存在)

证书验证:

  1. 系统会通过B的签发者,找到它的签发者的证书A。
  2. 确定需要使用的加密算法,hash算法什么的乱七八糟的。
  3. 关键:使用A的公钥pu-A来解开B的数字签名。通常情况B的数字签名是sig-A-hash(pu-B)。前面说了,数字签名就是用私钥加密内容。B的数字签名就是用A的私钥pr-A对B的公钥pr-B散列加密获得的。
  4. 解开了签名,得到hash(pu-B)后,只要hash一下B证书中的pu-B,对比一下散列是否一样。就可以确定这个证书是否合法了。

同理,B证书如果颁发了C证书,也是这样来验证C证书的有效性。这样就形成了一条信任链。

信任链

转载请注明:旅途@KryptosX » 证书是如何打通信任链的?

【云栖快讯】阿里云栖开发者沙龙(Java技术专场)火热来袭!快来报名参与吧!  详情请点击

网友评论