ssl建立通道流程
通常ssl的运作流程
首先，ssl通信简单说是以不对称加密建立通道，以该通道进行对称加密通信。如下图所示，服务端自己会保存私钥，并且会让CA机构为自己的证书签名。这个证书里面有服务端的公钥，会发给客户端，并带上服务端的一个随机数。CA根证书一般都预装电脑上，客户端获得证书就会用预装的CA根证书检查并信任服务器证书拿出公钥。然后客户端也会计算一个随机数，用服务端公钥加密发给服务端，只有服务端私钥才能解密该信息，至此两端都交换了自己的随机数。然后两边都有对方和自己的随机数，就可以计算出一个对称密钥，通道就建立完毕了。之后的通信都是建立在该通道的对称加密上。
自签名CA签署服务器证书的运作流程
如果我们使用自签名CA签署服务端的证书（官方CA签一个证书很贵的），也会走上述流程。接着到客户端收到了服务端证书，由于没有对应的自签名CA安装在客户端，客户端一般是不会信任服务端证书的，也就不会交换随机数建立通道了。所以我们执行curl命令时会提示失败。
但是这种情况浏览器可以访问该服务器，是因为浏览器会自动忽略掉“客户端获得服务端证书就会检查并信任证书拿出公钥”这一步骤，直接拿出公钥，此时浏览器的地址栏旁边通常是红色的，表示ssl连接并不安全。当然，我们可以在客户端安装一下对应的自签名CA，浏览器就不会标红了。
客户验证服务器证书的合法性
具体客户端收到服务端证书如何信任它，主要依据这几点：
- 证书是否过期
- 签署服务器证书的CA是否可靠（自签名CA的情况下，客户端不认识这个CA，当然认为不可靠了）
- 证书的公钥是否能正确解开返回证书中的数字签名
- 服务器证书上的域名是否和服务器的实际域名相匹配（也就是服务器证书的CN填写的域名和客户端访问的域名是否一致，后面使用openssl会详细说明）
- 验证通过后，将继续进行通信，否则，终止通信
客户端认证
上述两种情况下，都可以设置建立ssl通道时，客户端也要发证书过来，然后服务端用CA根证书验证通过后，才决定继续下面的交换随机数。当然这是服务端决定的，这是因为有些服务端安全要求比较高。
但是，如果有这个步骤，服务端用CA根证书验证客户端证书时，只有和服务端同一个根证书签名的客户端证书才会被通过。所以，自签名证书的情况下，两边都要安装好同一个自签名证书为各自的证书签名；或者客户端直接和服务端用同样的密钥和证书也行。
为我们的ssl服务安装证书
自签名证书
上面说了，首先服务端会发送CA机构签名过的证书，这个签名是要钱的。所以我们自己的服务要走ssl，一般用自签名的证书就好。服务端发送自己服务端证书时，会把自签名证书一并发过去，客户端也会把服务端证书的公钥取出来，然后走上述流程。
# 生成自签名证书的私钥
openssl genrsa -out ca.key 2048
# 生成自签名证书（填写信息随意）
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
签名服务端证书
# 生成服务器私钥
openssl genrsa -out server.key 2048
# CN填写服务器域名，生成服务器证书请求（填写信息随意，CN不要和ca根证书重复，毕竟重复说明自己签自己，不合法的）
openssl req -new -key server.key -out server.csr
# CN填写服务器IP，生成服务器证书请求（填写信息随意，CN不要和ca根证书重复；CN填写服务器IP会识别不到，所以要在SAN指定好IP，生成服务器证书时要带-extfile参数）
openssl req -new -key server.key -out server.csr
echo subjectAltName = IP:xxx.xxx.xxx.xxx > extfile.cnf
# server.csr的CN填写服务器域名，生成服务器证书
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
# server.csr的CN填写服务器IP，生成服务器证书
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -extfile extfile.cnf -set_serial 01 -out server.crt
验证证书
openssl x509 -text -noout -in xxx.crt
评论区