本文介绍下SSL证书数据加密的过程，在这之前先简单说下抓包移动端网络请求工具的配置过程。

nginx 414 request-URI too large

手机端报如下错

通过抓包工具charles或fiddler，原理就是手机将电脑设置为代理服务器，手机访问网络请求经过电脑转发到互联网，那么在电脑上的抓包工具就可以抓到手机端的http/https请求了。

原因是http请求头太大了，超出了nginx默认的大小，所以配置下请求头大小即可

# 在http中配置  # 允许客户端最大的 body 长度，nginx会通过检查 Content-Length 来判断， 如果超过会返回 413 错误码。 将该值设置为 0，禁用该检查项client_max_body_size  200m;# 用于接收 http 头部的缓冲区，一般这个大小是足够的，如果超过，会启用 large_client_header_buffersclient_header_buffer_size 512k;# 设置了用于接收较大客户端头部的缓冲区最大数与大小。当请求行超过一个缓冲区大小后，会返回 414 错误码，如果是某个头部超过，会报 400 错误码large_client_header_buffers 4 512k;

抓包工具charles

找到添加好的证书

显示简介

始终信任

拷贝证书到系统

设置https抓包端口

所有IP，443端口

查看电脑IP

en0 192.168.1.4

查看电脑已连接的wifi密码，launchpad-其他-钥匙串

电脑和手机需要在同一个局域网内（手机和电脑连接同一个WI-FI）, 手机设置电脑为代理服务器，IP设置为电脑的IP，端口设置为8888

手机安装Charles证书，使用Chrome浏览器访问"chls.pro/ssl"（注意：一定要使用Chrome浏览器，安卓国产浏览器会将证书视为下载文件，不能直接安装）或者手机微信点开这个链接，此时电脑上连接提示，点击allow允许

此时用手机访问互联网，就会经过电脑转发了，

https证书的原理

https其实不是一个的协议 ，只不过在http的基础之上用TLS/SSL进行加密，这样通信就不容易受到拦截和攻击。

SSL是TLS的前身，都是加密安全协议，现在绝大部分浏览器都不支持SSL，而是支持TLS，不过SSL的名气很大。

发送方和接收方用同样的规则为数据进行加密，用同样的钥匙来解开密文，这就是对称加密。

非对称加密

服务端拥有成对的公钥和私钥，公布自己的公钥让客户端知道，客户端用公钥把自己的数据进行加密，加密后，公钥无法解密这段数据，一定要用服务端的私钥才能解密，这是非对称加密，也叫公钥加密。不同于对称加密：只有一把密钥。

加解密保证了数据安全，你发给我的数据，用我的公钥加密，这个密文只有我的私钥才可以解密。

签名/验签保证了数据来源的安全，你发送给我的数据，用你自己的私钥签名下，我这边用你的公钥验证下，确认下来源是否来自于你。

配置https证书

在nginx的配置文件中配置ssl证书

server_name是域名，可以配置一级域名和多个二级域名，共用同一个证书。

ssl_certificate配置证书的pem文件，ssl_certificate_key配置的是证书的key。如果只有crt文件，没有pem文件，可以通过crt生成pem文件，

openssl x509 -in xxxx.crt -out xxxx.pem

证书配置好后，访问域名，

显示连接是安全的。查看证书信息，

这个证书就是在服务器上nginx中配置的ssl证书。

要让ssl证书生效就需要向CA申请（即Certificate Authority，证书授权中心），这是第三方的机构，这样大家都来信任这个机构颁发的证书，这个证书除了表明域名是属于谁的、日期等等信息以外，最重要的是这个证书里包括了特定的公钥和私钥。简单来说服务器安装了ssl证书以后，用户就可以通过https来访问服务器了，当然浏览器也会把http的默认端口80改为https的默认端口443。

tcp三次握手

这是正常的http三次握手，接下来看下TLS1.2版本数据加密的过程，

客户端给服务端发送了一个Client Hello，在请求报文中，客户端会告诉服务端支持客户端支持的TLS1.2版本和支持的加密套件，

这里有16个加密套件可以理解为不同的加密算法组合，然后生成一个随机数然后发给服务端。

在服务端的响应报文中，

响应报文里会告诉客户端服务端确认之后的TLS版本以及选择使用的加密套件，

并且服务器也生成一个随机数发送给客户端。

接下来服务器会再发一个响应来出示服务器自己的证书，

这样浏览器就可以对照自己的证书信任列表来确认这个服务器是否可信。

发了证书当然少不了公钥，于是下一步 Server Key Exchange，就是服务器就把公钥发送给了客户端，但不会把私钥发送出去。

如果服务器也想要客户端的证书会在这里发出请求，比如登录网银就很可能需要这个步骤了。

服务器一下子发了这么多响应，最后还要告诉客户端发送完了，Server Hello Done

截止目前这些请求和响应依旧还未进行加密。现在就轮到客户端来处理这些响应了，

客户端会生成第三个随机数，

也叫预主密钥，这第三个随机数会用刚刚收到的公钥进行加密，并且把这个加密后的随机数发送给服务器，正是这里pubkey显示的随机数。

接下来就是Change Ciper Spec，

这一步就是告诉服务器往后的数据就用商议好的算法和密钥来加密。

最后Encrpted Handshake Message表示客户端这边TLS协商的没有问题，加密可以开始了

同样的服务器也发来了Encrypted Handshake Message，

表示服务器这边准备好了，这里也表示TLS的握手已经成功了，可以给数据加密进行交换了。

总结SSL数据加密的过程

客户端把自己支持的TLS版本、加密套件、随机数（这是整个过程中的第一个随机数）发给服务器，服务端确认支持的TLS版本以及选择的加密套件，并且服务器也生成一个随机数发给客户端，这是第二个随机数，接着服务端把证书和公钥发送给客户端，都发送完毕就告知客户端。现在客户端这边生成随机数，这是第三个随机数：预主密钥，这个预主密钥不会发送出去，而是用刚刚收到的公钥进行加密后再发送出去，Client Key Exchange、Change Ciper Spec、Encrpted Handshake Message (用公钥加密后的第3个随机数/预主密钥)，然后客户端这边的TLS协商好了，加密开始，服务端收到加密后的预主密钥后，会用自己的私钥进行解密，这样服务端就知道预主密钥了，而且只有客户端和服务端知道这预主密钥。

因为没有进行直接传输，没有其他人知道这预主密钥是什么，除非私钥被泄漏了。

最后客户端用预主密钥、第1随机数、第2随机数计算出会话密钥，服务端也用预主密钥、第1随机数、第2随机数计算出会话密钥，各自得到的会话密钥是相同的。

前面的步骤都是非对称加密，都是为了得到这个会话密钥。后面的话 ，大家都只使用这个会话密钥对数据进行加密，也就是后面使用的是对称加密，大家都使用同一个密钥。会话后面不使用非对称加密是因为消耗资源非常，而且得到会话密钥之后，就没人知道密钥是什么了，因此后面使用对称加密。

如果与其他服务器沟通就会建立新的会话，会话密钥也不相同，会话密钥只应用在当前会话，更加提高了安全性。