问：非对称加密中一般公钥用来加密，私钥用来解密，虽然私钥加密理论上可行，但由于数学上的设计这么做并不适合，那么私钥就只有解密这个功能了么?
答：
私钥除了解密外的真正用途其实还有一个，就是数字签名，其实就是一种防伪技术，只要有人篡改了证书，那么数字签名必然校验失败，只有CA机构的私钥可以用来做数字签名。
加签名的是CA机构用自己的私钥加的签名，不是服务端的私钥。
注意，这里有一个比较难以理解的地方，非对称加密的签名过程是
1.网站把自己的证书发给CA机构申请签名：CA机构将网站的证书加签名（要用到CA机构自己的私钥），然后将签名和证书明文一起发送给网站服务器，网站的证书变为CA证书。
2.服务器收到客户端请求后，将CA证书发给客户端。
3.客户端收到CA证书后用CA签名验证该证书的真实性（具体过程是，客户端使用信任的CA机构的公钥给签名解密，如果解密出来的哈希值和证书本身的哈希值一致，表明证书没有被篡改）
当然，上面的过程能完成的前提是——网站去给证书申请签名的CA机构和客户端用某CA机构公钥解密的是同一个CA机构。就是说网站和客户端必须信任同一个CA机构才行。
如果HTTPS请求到的CA证书来自于一个客户端不信任的CA机构（客户端没有该CA机构的公钥,无法验证证书的真实性），就会收到提示。
问：网站服务器通信时，证书上有自己的公钥，那么必定也有一个私钥用于解密，那么能不能用自己的私钥给自己的证书加签名？
答：可以的, 当然自签名的证书不会被浏览器信任,所以客户访问的话影响不好,浏览器提示的各种错误很多,可以淘宝一个Gworg SSL证书,价格比较合理,适合您当前的情况。
问：只有一组公钥私钥只能保证单程的加解密，那么如果我们准备两组公钥私钥就行了啊，为什么HTTPS不使用双向非对称加密?
答：
- 服务端有非对称加密的公钥 A1，私钥 A2。
- 客户端有非对称加密的公钥 B1，私钥 B2。
- 客户端向服务端发起请求，服务端将公钥 A1 返回给客户端。
- 浏览器收到公钥 A1，将自己保存的公钥 B1 发送给服务端。
- 之后浏览器所有向客户端发送的数据，使用公钥 B1 加密，客户端可以使用私钥 B2 解密。
- 客户端所有向服务端发送的数据，使用公钥 A1 加密，服务端可以使用私钥 A2 解密。
此时，两条传输方向的数据都经过非对称加密，都能保证安全性，那么为什么不采用这种方案呢?
最主要的原因是非对称加解密耗时要远大于对称加解密，对性能有很大损耗，大家的使用体验很差。
所以，我们HTTPS才最终选用了非对称加密+对称加密的方案
问：服务端返回公钥的时候被截获了，一样不安全，咋办？
答：
出现这一问题的核心原因是客户端无法确认收到的公钥是不是真的是服务端发来的。为了解决这个问题，
服务端在使用 HTTPS 前，自己给自己发一个证书（没有签名的），证书里包含有证书持有者(xx公司)、域名(https://xx/)、公钥(j32jh23)等信息。
服务端将证书发送给客户端，客户端校验证书身份和要访问的网站确实一致后再进行后续的加密操作。
有了证书后，中间人也变聪明了，只改动了证书中的公钥部分，客户端依然不能确认证书是否被篡改，所以，没有签名的证书同样不能保证安全。
所以需要给证书加签名。网站服务器将该证书发给信任的CA机构，让其给证书加上该CA机构的数字签名。
具体过程如下：
- CA 机构拥有自己的一对公钥和私钥。
- CA 机构对证书明文信息进行哈希，得到哈希值H。
- 将哈希值H用私钥进行加密，得到数字签名Sig。
证书明文和数字签名组成证书，传递给客户端：
- 客户端得到证书，分解成证书明文部分 Text 和数字签名 Sig。
- 用 CA 机构的公钥将签名Sig解密，得到哈希值 H。(由于 CA 机构是一种公信身份，因此在系统或浏览器中会内置 CA 机构的证书和公钥信息)。
- 用证书里声明的哈希算法对明文 Text 进行哈希得到 H1。
- 如果H1与H相等，表示证书可信，没有被篡改。
这时，签名是由 CA 机构的私钥生成的，如果中间人篡改证书，那么在客户端验证数字签名就会失败，这样就保证了证书可信。
可以看出来，服务端和客户端必须有都信任的CA机构。
问：CA机构的私钥泄露会有什么后果？
答：如果CA机构的私钥泄露，攻击者可以将“假的证书”（内置了自己公钥的证书），用私钥加密后发给客户端，客户端将“假的证书” 用CA机构的公钥进行校验发现证书没有被篡改，
实际已经被篡改了，所以，CA机构的私钥泄露将导致信任该CA机构的客户端使用HTTPS协议不再安全。