【PKI、数字证书制作与HTTPS部署】

最新推荐文章于 2024-09-12 14:04:29 发布

d2q

最新推荐文章于 2024-09-12 14:04:29 发布

阅读量1.2k

点赞数 39

文章标签： https 网络协议 http

本文链接：https://blog.csdn.net/m0_64237310/article/details/141863617

版权

文章目录

PKI 组成与功能
数字证书原理
制作中间数字证书，部署 HTTPS

PKI 组成与功能

组成

证书颁发机构（CA）
注册机构（RA）
证书存储库
证书撤销列表（CRL）
公私钥
功能
认证
数据完整性
机密性
不可否认性

数字证书原理

对称加密和非对称加密

当我们访问一个 http 网页，浏览器会提示这并不安全。这是因为，在我们和浏览器通讯时，中间人可以监控明文数据包。
那么，我们对数据包进行打码，这样极大地增加了中间人辨认内容的难度。
我们和网站之间有两把一样的私钥：我们发送报文时，先用私钥加密，发送给网站，网站再用私钥解密。这就是对称加密。
中间人没有私钥就很难对截获的报文解密。而且私钥是有期限的，每一次会话都需要一把私钥，我们在此称为会话密钥。这样对于中间人就更难破译了。
但用户和网站怎么传递私钥来避免中间人截获呢？
网站发送公钥给用户，用户利用公钥将明文加密发送过去，网站利用私钥进行解密，就得到了明文。这样用户和网站都可以生成会话密钥，中间人只有密文和公钥无法生成密钥。这种利用公私钥的方式叫做非对称加密。这就真的安全吗？试想下面这种情况：
网站要向用户发送公钥，中间人截获后，扣住公钥，自己伪造公私钥，将假公钥发给用户，用户收到公钥，将明文用假公钥加密，发给中间人，中间人用私钥解密，读取明文，再用真公钥加密发送给网站。这样生成的会话密钥是用户和中间人，中间人和网站的，用户和中间人并未生成会话密钥。这样还是防不住。
这就是没有 https 的有一个缺点，无法保证完整性。

数字证书

上面的问题在于无法保证公钥是来自网站的还是中间人的。这里就要引入权威的第三方（Certificate Authority 证书颁发机构）来做公证。
这样子流程就有点变了，首先网站将公钥发送到 CA，CA 根据这把公钥以及其他信息生成了证书，该证书将公钥与其网站绑定到一起。
然后将证书发给用户，用户看到是值得信任的 CA，就从证书中取出公钥，最后就能开心的生成会话密钥与网站通信了。这样就安全了吗？并不是，我们如何相信数字证书是由收信任的 CA 颁发的呢？那么就要在证书上加上 CA 的签名了。

数字签名

CA 收到网站的信息和公钥后，会对这些信息以及公钥进行 hash 运算，得到 hash 字符（如果内容被修改了，hash 运算后的结果完全不一样）。
hash 运算以后，CA 自己也生成一对用于数字证书的公私钥，然后用私钥对 hash 字符加密，这串加密后的字符就是数字签名了。这样 CA 就将含有签名的证书发回网站了。
当用户和网站通信时，为了证明公钥没有被中间人修改过，用户利用数字签名是生成的公钥对数字签名解密，得到 hash 字符，接着对收到的内容进行同样的 hash 运算，然后比对 hash 字符即可。如果匹配就可以认为没有被中间人篡改了。
但是我们如何安全的拿到 CA 的公钥呢？其实 CA 也需要证书来证明他的公钥。