1.第一次传输对称密钥为明文传输，不安全。
2.密钥存储问题。
对称密钥的问题主要在于：在第一次传输密钥时，这个密钥怎么让传输的双方知晓，同时不被别人知道。
如果由服务器生成一个密钥并传输给浏览器，那这个传输过程中密钥被别人劫持弄到手了怎么办？之后他就能用密钥解开双方传输的任何内容了，所以这么做当然不行。
有两把密钥，通常一把叫做公钥、一把叫做私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。
服务器先把公钥直接明文传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传。
而服务器则使用私钥加密传输，客户端通过公钥解密。
问题：第一次明文传输公钥时，中间人可以拿到这个公钥，虽然此公钥不能解开由客户端加密传输的数据，但是服务端加密传输的数据，是不安全的。
非对称加密只能保证由浏览器向服务器传输数据时的安全性。
非对称加密+对称加密结合可以吗？而且得尽量减少非对称加密的次数。当然是可以的，而且非对称加密、解密各只需用一次即可。
请看一下这个过程：
某网站拥有用于非对称加密的公钥key1、key1’。
浏览器像网站服务器请求，服务器把公钥key1明文给传输浏览器。
浏览器随机生成一个用于对称加密的密钥key2，用公钥key1加密后传给服务器。
服务器拿到后用非对称私钥key’解密得到密钥key2。
这样双方就都拥有密钥key2了，且别人无法知道它。之后双方所有数据都用密钥key2加密解密。
问题：
中间人在第一次明文传输非对称公钥的时候，劫持此公钥，然后中间人自己也创建一份公钥与私钥，公钥发给客户端，私钥自己留着，客户端用中间人的公钥加密了对称密钥key2发给中间人，中间人用自己私钥拿到key2，我们继续再看，中间人用最开始劫持的公钥加密key2，然后发给服务端，服务端用自己私钥拿到key2，以后服务端与客户端还是用key2通信，但是key2已经被中间人拿到手了。
中间人利用自己创建的公钥拿到了客户端的对称密钥，利用服务端的公钥加密传输对称密钥。
解决问题的关键点：公钥有没有被劫持并不重要，重要的是怎么证明客户端收到的公钥一定是服务端的公钥，而不是中间人的公钥。
现实生活中，如果想证明某身份证号一定是小明的，怎么办？看身份证。这里***机构起到了“公信”的作用，身份证是由它颁发的，它本身的权威可以对一个人的身份信息作出证明。互联网中能不能搞这么个公信机构呢？给网站颁发一个“身份证”？
数字证书网站在使用HTTPS前，需要向“CA机构”申请颁发一份数字证书，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取公钥就行了，证书就如身份证一样，可以证明“该公钥对应该网站”。然而这里又有一个显而易见的问题了，证书本身的传输过程中，如何防止被篡改？即如何证明证书本身的真实性？身份证有一些防伪技术，数字证书怎么防伪呢？解决这个问题我们就基本接近胜利了！
如何放防止数字证书被篡改？我们把证书内容生成一份“签名”，比对证书内容中的签名和和生成的签名是否一致就能察觉是否被篡改。这种技术就叫数字签名。
数字签名这部分内容建议看下图并结合后面的文字理解，图中左侧是数字签名的制作过程，右侧是验证过程（原图出处找不到了，可以看出来这图已经被转载了无数次了。。。）
数字签名的制作过程：
CA拥有非对称加密的私钥和公钥。
CA对证书明文信息进行hash。
对hash后的值用私钥加密，得到数字签名。