数字签名是为了确保信件信息未被篡改，数字证书是为了确保获得的公钥合法。
数字签名
数字签名的目的是保证收件人能够确定此信件的来源正确并且未被篡改过。
数字签名的流程如下：
首先发件人使用HASH函数，生成了信件的摘要（Digest）
发件人使用自己的私钥对摘要进行加密，从而生成了此封信件的数字签名（Signature）
发件人将此数字签名附在信件中，发送给收件人
收件人收到信件后，使用公钥对数字签名进行解密，得到了信件摘要（Digest），从而证明了此信件确实是由发件人寄出的（公钥正确的前提下）。
收件人再对信件内容进行HASH，将得到的结果与上一步的Digest进行对比，如果相同则证明此信件未被篡改过。
数字签名的流程中，有一步存在风险。那就是收件人获得的公钥未必正确。为了确保收件人持有的公钥是正确的，因此引入了数字证书的概念。
数字证书
数字证书是证书中心（CA，certificate authority）为公钥颁发的凭证。证书中心（CA）用自己的私钥，对发件人的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。
数字证书的流程如下：
发件人向CA申请数字证书，证书中包含了发件人的个人信息，证书的信息，发件人的公钥
发件人拿到数字证书以后，将签名和数字证书同时附在信件中
收件人收到信件后，使用CA的公钥解开数字证书，就可以获得真实的公钥了
数字证书和HTTPS
HTTPS实际上就是HTTP协议和SSL/TSL协议的组合，可以把HTTPS大致理解为“HTTP over SSL”或“HTTP over TSL”。关于它们的相关介绍，可以参考这篇文章。对于HTTPS我们应该有以下几个认知：
1）使用HTTPS传输数据是安全的，因为数据都是被加密传输的；
2）使用HTTPS需要在服务器端配置密钥对；
3）使用HTTPS需要花钱找专业的权威机构进行CA证书的签发。
那么使用HTTPS与网站服务器进行交互的流程和原理到底是怎样的呢？让我们先以逆向思考的方式来进行说明：
我们说过，公钥加密/非对称加密方式虽然安全，但是由于密钥过长，加密和解密速度都远远低于对称加密。因此，出于对性能方面的考虑，HTTPS并不是把所有传输的数据都使用公钥加密的方式进行机密性的保护，而是继续使用对称加密的方式来加密数据。还有一个原因就是，使用公钥机密算法来保证数据机密性的话，需要通信双方都要有密钥对儿，否则总有一方发出的数据是能被对方公布的公钥解密的。
既然时使用对称加密的方式加密数据，就需要有一个通信双方都知道的加解密所使用的密钥。HTTPS是通过上面提到的密钥交换技术来动态协商这个密钥的，实际上就是由客户端生成一个随机密钥，然后发送给服务器端，这样就解决了密钥的管理问题。
既然说HTTPS是安全的，那么客户端生成的这个随机密钥肯定不能以明文的方式发送给服务器端啊。是的，当客户端以https的方式访问一个站点时，该站点会自动下发其公钥信息。客户端会使用这个公钥对产生的随机密钥进行加密，然后传送给服务器端。服务器端以自己的私钥对这个密文进行解密，然后得到这个密钥的明文内容。至此，客户端与服务端用于对称加密和解密的密钥协商与传输工作已经安全的完成了。
那么要通过网络获取服务器端的公钥信息，那么怎么验证该公钥信息的合法性呢？我们上面说过，不是所有问题都能依赖技术来解决的。这里要验证公钥信息的合法性就要依靠CA证书签发机构了，网站服务的提供者必须找一个大家都信任的机构来对他提供的公钥进行签名，用户得到一个网站下发的公钥后看到有这个机构的签名就认为这个公钥是合法的，是可信赖的。
那么CA机构的签名要以什么样的形式来提供呢？实际上网站服务器下发给客户端（通常是浏览器）的公钥已经不仅仅是密钥对儿中公钥的内容了，而是包含了证书签发机构写入的其他信息的CA证书。这个CA证书中包括证书签发机构的标识和公钥的数据指纹，当然还有包含网站服务提供者的公钥信息以及证书到期时间等等。但是，我们前面提到过，单向加密只能保证数据的完整性，不能保证数据机密性。CA证书的伪造者完全可以伪造公钥信息并生成相应的数据指纹，然后发送给用户。那么现在的问题就变成了要验证CA证书中公钥的合法性以及CA证书提供者的身份了。貌似问题只是转移了，而没有被解决。
其实每个CA证书的签发机构也都有自己的密钥对儿，他们放在CA证书中的公钥的数据指纹时通过自己的私钥加密过的，而这些CA证书签发机构的公钥是被各浏览器厂商内置在浏览器内部的。当浏览器接收到某网站服务器下发的CA证书后会根据CA证书中签发机构的标识来读取浏览器内置的相应CA签发机构的公钥信息，通过这个公钥信息对公钥数据指纹的密文进行解密就可以得到CA证书中包含的公钥信息的真实数据指纹。浏览器再通过单向加密的方式自己计算一次CA证书中包含的公钥信息的数据指纹，两个数据指纹一致则说明这个CA证书确实是该CA机构签发的，同时也证明了CA证书中的公钥信息没有被篡改过。至此，所有的问题就都解决了。
现在我们再来以正常的顺序描述一下使用HTTPS与网站服务器进行交互的过程：
1）浏览器A与网站服务器B通过三次握手后建立网络连接。
2）浏览器A告诉网站服务器B：我想跟你通过HTTPS协议进行秘密交流。
3）网站服务器B把包含自己公钥信息的CA证书下发给浏览器A，并告诉浏览器A这个CA证书里有我的公钥信息，你决定一个对称加密使用的秘钥串，然后通过这个公钥加密后发送给我。
4） 浏览器A接收到网站服务器B下发的CA证书后，对这个CA证书的及其包含的公钥信息的合法性表示怀疑。于是根据CA证书中包含的证书签发机构的标识找到自身内置的该签发机构的公钥对CA证书中公钥的数据指纹进行解密，然后再自己计算一下CA证书中公钥的数据指纹，对了一下这两个数据指纹是一致的。浏览器A放心了，知道这个CA证书是合法的，CA证书中的公钥也没有被篡改过。
5）然后浏览器A通过通过密钥协商技术产生了一个随机的字符串作为与网站服务器B进行秘密通信的密钥，并把这个密钥通过CA证书中包含的公钥进行加密后发送给网站服务器B。
6）网站服务器B接收到密文格式的密钥后，通过自己的私钥进行解密得到密钥的明文内容。
7）浏览器A和网站服务器B开始了秘密交流。
