数字证书的理解
前言
「公开**加密」和「数字签名」无法保证公开**确实来自信息的发送者。因此，就算公开**被第三者恶意替换，接收方也不会注意到。数字证书可以完美的解决这一问题，保证公开**的正确性。
处理流程图解
A持有公开**PA和私有秘钥SA，现在想要将公开**PA发送给B。
-
首先，A需要向认证中心申请发行证书，证明公开**PA确实由自己生成。
-
认证中心里保管者他们自己准备的公开**PC和私有秘钥SC。
-
A将公开秘钥PA和包含邮箱信息的个人资料发送给认证中心。
-
认证中心对收到的资料进行确认，判断其是否为A本人的资料。确认完毕后，认证中心使用自己的私有秘钥SC，根据A的资料生成数字签名。
-
认证中心将生成的数字签名和资料放进同一个文件中。
-
然后，把这个文件发送给A
-
A的数字证书如下
-
A将作为公开**的数字证书发送给了B。
-
B收到数字证书后，确认证书里的邮件地址确实是A的地址。接着，B获取了认证中心的公开**。
-
B对证书内的签名进行验证，判断它是否为认证中心给出的签名。证书中的签名只能用认证中心的公开**PC进行验证。如果验证结果没有异常，就能说明这份证书的确由认证中心发型。
-
B确认了证书是由认证中心发行的，且邮件地址就是A的之后，B从证书中取出A的公开**PA。这样，公开**便从A传到了B。
数字证书的安全性
假设X冒充A，准备向B发送公开**PX。
但是，B没有必要信任以非证书形式收到的公开**。
假设X为了假冒A，准备在认证中心登记自己的公开**。然后X无法使用A的邮箱地址，因此无法获得A的证书。
原理解析
通过数字证书，信息的接收者可以确认公开**的制作者。
B得到了认证中心的公开**，就一定来自认证中心吗？
由于公开**自身不能表示其制作者，所以有可能是冒充认证中的X所生成的。也就是说，这样同样存在公开**问题。
实际上，认证中心的公开**PC是以数字证书的形式交付的，会有更高级别的认证中心对这个认证中心署名。
例如，下图的树结构，上面的认证中心为下面的认证中心发行证书。那么，这个树结构是怎么生成的，假设存在一个被社会广泛认可的认证中心A。此时出现了一个刚成立的公司B，虽然B想要开展认证中心的业务，但它无法得到社会的认可。
于是，B向A申请发行数字证书。当然A会对B能否开展认证中心业务进行适当检测，只要A发行了证书，公司B就可以向社会表示自己获得了公司A的信任。于是，通过大型组织对小组织的信赖担保，树结构就建立了起来。
最顶端的认证中心被称为“根认证中心”，其自身的正当性由自己证明。对根认证中心自身进行证明的证书为“根证书”。如果根证书不被信任，整个组织就无法运转。因此根认证中心多为大型企业，或者与政府关联且已经取得了社会信赖的组织。
数字证书在网站中的运用
上面讲述的是个人之间交付公开**的例子，在网站之间的通信也要用到数字证书。只要能收到来自网站的含有公开**的证书，就能确认该网站未被第三者冒充。
此处的证书叫作“服务器证书”，同样由认证中心发行。个人的证书与他的有邮箱信息相对应，而服务器证书与域名信息相对应。因此，我们还可以确认网站域名和存储网站本身内容的服务器是由同一个组织来管理的。
数字证书就是像这样通过认证中心来担保公开**的制作者，这一系列技术规范被统称为“公钥基础设施”。
HTTPS数字证书
网站配置https访问时，需要向相关权威机构申请数字证书，申请到数字证书后，将数字证书配置到项目里。我们就可以用浏览器通过https来访问这个网站了，这个权威机构是被浏览器官方授予了颁发权限，所以此处根节点是浏览器。
如图所示，一个开启了https的网站，给你颁发证书的机构是浏览器官方指定的，所以浏览器就会显示连接是安全的。