当我们配置https时我们在配置什么

当我们想让我们的网站支持https时，我们需要做什么，以及这些过程中的原理是什么呢？

申请并配置一个HTTPS证书

我们先从申请者的视角触发

首先我们要生成一对密钥

#私钥
openssl genrsa -out server.key 1024
#公钥
openssl rsa -in server.key -pubout -out server.pub

然后我们要把公钥跟其他一些信息打包起来成为一个叫做csr（Certificate Signing Request）的文件

openssl req -new -key server.pub -out server.csr
#接下来会提示你输入一些信息，比如申请域名、服务器所在地等

得到这个server.csr文件之后，我们把这个csr提交给CA（Certificate authority）

然后我们把视角切换到CA。

我们在这里先讨论根CA的情况，即CA的证书是自己生成而非由另一个CA颁发的情况。
CA在成为CA的时候，他首先创建自己的一对密钥ca.key和ca.pub以及相应的ca.csr，然后使用以下代码进行自签发

openssl x509 -req -days 365 -sha1 -extensions v3_ca -signkey \
ca.key-in ca.csr -out ca.crt

得到一个ca.crt文件，这就是CA的证书
当CA收到申请者的server.csr文件后，会先通过一些方法验证这个申请者的资格，跟证书的原理无关，我们略过。然后用以下代码进行签发

openssl x509 -req -days 365 -sha1 -extensions v3_req -CA ca.cer -CAkey ca.key\
-CAserial ca.srl -CAcreateserial -in server.csr -out server.crt
#其中ca.srl是一个证书序列文件，相当于给每个签发的证书一个唯一编号，这里不详述

这段代码大概做了这些事：

• 将server.csr和ca.csr里的信息一起做一个散列计算，得到一个hash值，我们标记为s_hash
• 用CA的私钥ca.key给这段s_hash加密，得到s_sign，就是我们一般说的签名
• 然后把这段s_sign和之前的server.csr以及ca.csr组合起来，就成为颁发给申请者的证书server.crt了
  如果是二级及以上CA，实际上只需要把自签发部分换成找上级CA签发就行。

再把视角转回申请者

这时候我们得到了CA返回的server.crt证书了，如何配置呢？我们这里以nginx举例
在nginx配置里写上这样的代码

ssl_certificate /your_path/server.crt;
ssl_certificate_key /your_path/server.key;

服务器端的配置至此结束，接下来我们看看https使用时的流程

https通讯过程

客户端（操作系统或浏览器）在发起一个HTTPS请求的时候，会把一组加密算法（对称加密）和一个随机数CilentRandom发送给服务器。

服务器从这些算法中选出一个，并生成一个随机数ServerRandom，把这些数据和自己的证书返回给客户端。

客户端收到服务器证书之后，查看这个证书的颁发机构是否受信任（通常操作系统或浏览器都会自带一个信任CA列表）。
具体方法是
1.查看服务器证书server.crt中的CA字段，是否在信任列表中，若否，则直接判定不可信。需要注意的是这里会把整个证书链都进行验证，直到根证书。
2.使用记录的CA公钥来解密server.crt中的签名，就是上文提到的s_sign，得到s_hash_1，然后再把server.crt中的其他信息进行HASH计算，得到s_hash_2，如果二者匹配，则说明证书可信。

确认证书可信之后，客户端再生成一个随机数PremasterSecret，并使用证书中的服务器公钥进行RSA加密，得到消息A，发送给服务器。

服务器使用自己的私钥对消息A进行RSA解密，得到PremasterSecret。

此时，客户端和服务器都同时拥有了CilentRandom，ServerRandom，PremasterSecret三个随机数，用协议规定的方式组合成SessionKey。至此https握手阶段完成，接下来就是普通的http请求，只是数据都用约定好的加密方式和SessionKey进行对称加密。

待回答的问题

我们为什么要使用HTTPS而不是普通的HTTP？HTTPS是否真的可靠？上文提到的对称加密和非对称加密又有什么区别？

To be continue