在介绍数字证书前，先谈谈签名/验签的流程，当 A 向 B 发送数据，
A 先通过非对称加密算法，生成一对公钥和私钥，并把公钥公开
使用消息摘要算法（如 SHA、MD5 等），生成数据的摘要信息
使用私钥“加密”得到签名，并将签名附加在数据上，一起发送给 B
这个流程称为签名。
B 收到后，
用消息摘要算法生成摘要
用公钥“解密”签名得到 A 生成的摘要
两个摘要比对，如果一致则说明没有第三方修改。
这个流程称为验签。
但这里如果 B 所保存的公钥被 C 篡改成 C 的公钥了，C 就可以伪装成 A 和 B 进行交流了。
所以 A 可以去可靠的数字证书认证机构（即 CA，Certificate Authority）对自己的公钥进行认证，CA 会用自己的私钥“加密” A 的信息和公钥，得到签名，并把 A 的信息、公钥、签名放在一起，这就是数字证书。
这样 C 即使篡改了数字证书中 A 的公钥，B 只需要用 CA 公开的公钥进行刚才所说的验签流程，即可验证了。
其实，CA 使用私钥签名，公开公钥进行验签，和 A 与 B 之间发送数据的流程是类似的。那 CA 所公开的公钥是不是也可能被篡改？解决方案是后面的证书链。
先总结一下：
数字证书包含了公钥、公钥持有者信息、签名以及证书有效期等信息，它是用来认证公钥、公钥持有者身份的电子文件。最常用的证书格式是 X.509 标准。
数字证书认证机构（CA）是证书的签发机构，它是 PKI 的核心。CA 是负责签发证书、认证证书、管理已颁发证书的机关。它要制定政策和具体步骤来验证、识别用户身份，并对用户证书进行签名，以确保证书持有者的身份和公钥的拥有权。
数字证书签发/验证流程
有个很经典的图，讲了大概流程：
证书链
打开一个支持 HTTPS 的网站，可以点击地址栏的小锁，查看这个网站的证书信息，可以看到证书路径：
这里有 3 级证书，它们被分为：
end-user：即 www.google.com，是该网站使用 HTTPS 安装的数字证书
intermediates：即 Google Internet Authority G3，是给 end-user 签发证书的中间 CA 的证书，中间 CA 可能不止一个
root：即 Google Trust Services - GlobalSign Root CA-R2，是根 CA 的证书，它给中间 CA 签发证书
证书链的形成
root 证书：由根 CA 自己对自己签发的
intermediates 证书：根 CA 生成一对公钥、私钥，并用私钥将中间 CA 的信息和公钥进行“加密”生成签名，并封装得到 intermediates 证书。上一级 CA 也是按照这个逻辑给下一级 CA 进行签发证书。
end-user 证书：最后的 CA 生成公钥私钥，并私钥将用户信息、公钥进行“加密”得到 end-user 证书
证书这一级一级的关系就形成了证书链。
为什么需要证书链
刚才也提到了，可以保证中间 CA 公开的公钥安全，并且如果中间 CA 的私钥泄漏了，那用根 CA 再签发一个就好了，不会影响到这个根 CA 的所有证书。GoDaddy 是这样描述的：
Intermediate certificates are used as a stand-in for our root certificate. We use intermediate certificates as a proxy because we must keep our root certificate behind numerous layers of security, ensuring its keys are absolutely inaccessible.
However, because the root certificate itself signed the intermediate certificate, the intermediate certificate can be used to sign the SSLs our customers install and maintain the "Chain of Trust."
根证书可信吗
根证书大部分是内嵌在软件中（如浏览器、操作系统），所以理论上是可信的，当然也可以自己下载安装证书。Apple 官网 可以看到 macOs 所支持的根证书。在 Windows 上可以运行 certmgr.msc，结果如：
