服务器如何把证书发送给客户

A. https交互过程

在这里整理一下最近这两天整理的https的相关知识。

大家都知道要使用https，需要在网站的服务器上配置https证书（一般是nginx，或者tomcat），证书可以使用自己生成，也可以向专门的https证书提供商进行购买。这两种的区别是自己生成的证书是不被浏览器信任的,所以当访问的时候回提示不安全的网站，需要点击信任之后才能继续访问

自己生成的

而购买的https证书会提示安全

DV,OV

EV

这是因为浏览器中预置了一些https证书提供商的证书，在浏览器获取到服务器的https证书进行验证的时候就知道这个https证书是可信的；而自己生成的证书，浏览器获取到之后无法进行验证是否可信，所以就给出不安全的提示。

下面对具体的一些知识点进行介绍

1. 什么是https

https简单的说就是安全版的http，因为http协议的数据都是明文进行传输的，所以对于一些敏感信息的传输就很不安全，为了安全传输敏感数据，网景公司设计了SSL（Secure Socket Layer），在http的基础上添加了一个安全传输层，对所有的数据都加密后再进行传输，客户端和服务器端收到加密数据后按照之前约定好的秘钥解密。

2. 加密和解密

Https的发展和密码学的发展是分不开的。大家应该知道加密方式可以大体分为对称加密和非对称加密（反正我就知道这两种）

对称加密，就是加密和解密都是用同一个秘钥，这种方式优点就是速度快，缺点就是在管理和分配秘钥的时候不安全。

非对称加密算法，非对称加密有一个秘钥对，叫做公钥和私钥，私钥自己持有，公钥可以公开的发送给使用的人。使用公钥进行加密的信息，只有和其配对的私钥可以解开。目前常见的非对称加密算法是RSA，非对称的加密算法的优点是安全，因为他不需要把私钥暴露出去。

在正式的使用场景中一般都是对称加密和非对称加密结合使用，使用非对称加密完成秘钥的传递，然后使用对称秘钥进行数据加密和解密

3. https证书的申请流程

1 在服务器上生成CSR文件（证书申请文件，内容包括证书公钥、使用的Hash算法、申请的域名、公司名称、职位等信息）

可以使用命令在服务器上生成；也可以使用线上的工具进行生成，线上的工具会把公钥加入到CSR文件中，并同时生成私钥。

CSR文件内容

2 把CSR文件和其他可能的证件上传到CA认证机构，CA机构收到证书申请之后，使用申请中的Hash算法，对部分内容进行摘要，然后使用CA机构自己的私钥对这段摘要信息进行签名，

CA机构进行签名

3 然后CA机构把签名过的证书通过邮件形式发送到申请者手中。

4 申请者收到证书之后部署到自己的web服务器中。下面会在写一篇关于部署的文章

当然这是不通过CA代理机构进行申请的流程，现在网上有好多CA的代理机构，像腾讯云，阿里云都可以申请https证书，流程都差不多。

阿里云申请证书流程

4. 客户端（浏览器）和服务器端交互流程

客户端服务端交互

client Hello,客户端（通常是浏览器）先向服务器发出加密通信的请求

（1） 支持的协议版本，比如TLS 1.0版。

（2） 一个客户端生成的随机数 random1，稍后用于生成"对话密钥"。

（3） 支持的加密方法，比如RSA公钥加密。

（4） 支持的压缩方法。

服务器收到请求,然后响应 (server Hello)

（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2） 一个服务器生成的随机数random2，稍后用于生成"对话密钥"。

（3） 确认使用的加密方法，比如RSA公钥加密。

（4） 服务器证书。

证书内容

证书内容

客户端收到证书之后会首先会进行验证

验证流程

我们知道CA机构在签发证书的时候，都会使用自己的私钥对证书进行签名

证书里的签名算法字段 sha256RSA 表示，CA机构使用sha256对证书进行摘要，然后使用RSA算法对摘要进行私钥签名，而我们也知道RSA算法中，使用私钥签名之后，只有公钥才能进行验签。

如果我们使用的是购买的证书，那么很有可能，颁发这个证书的CA机构的公钥已经预置在操作系统中。这样浏览器就可以使用CA机构的公钥对服务器的证书进行验签。确定这个证书是不是由正规的CA机构颁发的。验签之后得到CA机构使用sha256得到的证书摘要，然后客户端再使用sha256对证书内容进行一次摘要，如果得到的值和验签之后得到的摘要值相同，则表示证书没有被修改过。

如果验证通过，就会显示上面的安全字样，如果服务器购买的证书是更高级的EV类型，就会显示出购买证书的时候提供的企业名称。如果没有验证通过，就会显示不安全的提示。

生成随机数

验证通过之后，客户端会生成一个随机数pre-master secret，然后使用证书中的公钥进行加密，然后传递给服务器端

PreMaster secret

PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

pre-master secret

服务器收到使用公钥加密的内容，在服务器端使用私钥解密之后获得随机数pre-master secret，然后根据radom1、radom2、pre-master secret通过一定的算法得出session Key和MAC算法秘钥，作为后面交互过程中使用对称秘钥。同时客户端也会使用radom1、radom2、pre-master secret，和同样的算法生成session Key和MAC算法的秘钥。

生成session Key的过程中会用到PRF(Pseudorandom Function伪随机方法)来生成一个key_block,然后再使用key_block,生成后面使用的秘钥。

key_block = PRF(SecurityParameters.master_secret,"key expansion",SecurityParameters.server_random +SecurityParameters.client_random);

PRF是在规范中约定的伪随机函数

在信息交互过程中用到的秘钥有6个分别是。客户端和服务器端分别使用相同的算法生成。

秘钥名称秘钥作用

client_write_MAC_key[SecurityParameters.mac_key_length]客户端发送数据使用的摘要MAC算法

server_write_MAC_key[SecurityParameters.mac_key_length]服务端发送数据使用摘要MAC算法

client_write_key[SecurityParameters.enc_key_length]客户端数据加密，服务端解密

server_write_key[SecurityParameters.enc_key_length]服务端加密，客户端解密

client_write_IV[SecurityParameters.fixed_iv_length]初始化向量，运用于分组对称加密

server_write_IV[SecurityParameters.fixed_iv_length]初始化向量，运用于分组对称加密

然后再后续的交互中就使用session Key和MAC算法的秘钥对传输的内容进行加密和解密。

具体的步骤是先使用MAC秘钥对内容进行摘要，然后把摘要放在内容的后面使用sessionKey再进行加密。对于客户端发送的数据，服务器端收到之后，需要先使用client_write_key进行解密，然后使用client_write_MAC_key对数据完整性进行验证。服务器端发送的数据，客户端会使用server_write_key和server_write_MAC_key进行相同的操作。

链接：https://www.jianshu.com/p/b0b6b88fe9fe

B. SSL安全证书的实现机制

TLS/SSL的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

C. 用WireShark简单看看SSL/TLS协议

HTTPS目前是网站标配，否则浏览器会提示链接不安全，同HTTP相比比，HTTPS提供安全通信，具体原因是多了个“S”层，或者说SSL层[Secure Sockets Layer]，现在一般都是TLS[Transport Layer Security]，它是HTTP 明文 通信变成安全 加密通信 的基础，SSL/TLS介于应用层和TCP层之间，从应用层数据进行加密再传输。安全的核心就在加密上：

如上图所示，HTTP明文通信经中间路由最终发送给对方，如果中间某个路由节点抓取了数据，就可以直接看到通信内容，甚至可以篡改后，路由给目标对象，如下：

可见HTTP传输是不安全的，但，如果传输的是只有双方可校验的密文，就可以避免被偷窃、篡改，保证传输的安全性，这就是SSL/TLS层做的事情。

SSL/TLS协议主要从三方面来保证数据传输的安全性：保密、鉴别、完整：

对用户端而言：怎么保证访问的网站就是目标网站？答案就是 证书 。每个HTTPS网站都需要TLS证书，在数据传输开始前，服务端先将证书下发到用户端，由用户根据证书判断是否是目标网站。这其中的原理是什么，证书又是如何标识网站的有效性呢？证书也叫 digital certificate 或者public key certificate，是密码学中的概念，在TLS中就是指CA证书【 由证书的签发机构（Certificate Authority，简称为 CA）颁布的证书 】，好比是权威部门的公章，WIKI网络解释如下：

大意就是证书包含了目标站点的身份信息，并可以通过某种方式校验其合法性，对于任何一个HTTPS网站，你都可以拿到其CA证书公钥信息，在Chrome浏览器中点击HTTPS网站的锁标志，就可以查看公钥信息，并可以导出CA二进制文件：

浏览器就是通过这个文件来校验网站是否安全合法，可以看到，证书其实内置了一个颁发链条关系，根证书机构->次级证书机构->次次级->网站自身，只要验证这个链条是安全的，就证明网站合法，背后的技术其实是 信任链+RSA的非对称加密+系统内置根证书 。CA在颁发证书的时候，会用自己的私钥计算出要颁发证书的签名，其公钥是公开的，只要签名可被公钥验证就说明该证书是由该CA颁发的，核心校验逻辑如下

那么上级的CA又是如何保证安全呢？重复上述操作即可，最终都是靠根证书来验证的，根证书的安全性不需要验证，由系统保证，如此就形成了一个证书的信任链，也就能验证当前网站证书的有效性，证书的信任链校验如下：

TLS协议最大的提升点就是数据的安全，通HTTP通信相比，HTTPS的通信是加密的，在协商阶段，通过非对称加密确定对称加密使用的秘钥，之后利用对称秘钥进行加密通信，这样传输的数据就是密文，就算中间节点泄漏，也可以保证数据不被窃取，从而保证通信数据的安全性。

第三个问题，虽然中间节点无法窃取数据，但是还是可以随意更改数据的，那么怎么保证数据的完整性呢，这个其实任何数据传输中都会有这个问题，通过MAC[Message Authentication Codes]信息摘要算法就可以解决这个问题，同普通MD5、SHA等对比，MAC消息的散列加入了秘钥的概念，更加安全，是MD5和SHA算法的升级版，可以认为TLS完整性是数据保密性延伸，接下来就借助WireShark看看TLS握手的过程，并看看是如何实现身份鉴别、保密性、完整性的。

HTTPS安全通信简化来说： 在协商阶段用非对称加密协商好通信的对称秘钥 ，然后 用对称秘钥加密进行数据通信 ，简易的WireShark TLS/SSL协商过程示意如下：

细化分离后示意如下：

握手分多个阶段，不过一次握手可以完成多个动作，而且也并不是所有类型的握手都是上述模型，因为协商对称秘钥的算法不止一种，所以握手的具体操作也并非一成不变，比如RSA就比ECDHE要简单的多，目前主流使用的都是ECDHE，具体流程拆分如下：

Client Hello是TLS/SSL握手发起的第一个动作，类似TCP的SYN，Client Hello 阶段客户端会指定版本，随机数、支持的密码套件供服务端选择，具体的包数据如下

启动TLS握手过程， 提供自己所能支持各种算法，同时提供一个将来所能用到的随机数 。

ContentType指示TLS通信处于哪个阶段阶段，值22代表Handshake，握手阶段，Version是TLS的版本1.2，在握手阶段，后面链接的就是握手协议，这里是Client Hello，值是1，同时还会创建一个随机数random给Server，它会在生成session key【对称密钥】时使用。之后就是支持的供服务端选择的密码套件，接下来等服务端返回。

Handshake Type: Server Hello (2)，作为对Client Hello的响应 ， 确定使用的加密套件 : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)，密钥协商使用 ECDHE，签名使用 RSA，
数据通信通信使用 AES 对称加密，并且密钥长度是128位，GCM分组，同时生成一个服务端的random及会话ID回传。

这一步服务器将配置的证书【链】发送给客户端，客户端基于上文所述的证书链校验证书的有效性，这里发送的证书是二进制格，可以利用wireshark右键“Export Packet Bytes”功能，导出.CER格式的证书。如下可以看到传输的证书链。

导出的CER格式的证书如下，最关键的就其公钥跟数字签名。

Server Key Exchange是针对选定的ECDHE协商所必须的步骤，Diffie-Hellman模型解释如下：

大意就是ephemeral Diffie-Hellman不会使用证书中的静态公钥参与对称秘钥的生成，而是需要服务端与客户端通过彼此协商确定对称秘钥，而D-H算法模型需要两对非对称秘钥对，各端保留自己的私钥，同时握有双方的公钥，然后基于D-H算法双端可以算出一样的对称加密秘钥，而这就需要C/S互传自己的公钥

服务端做完这一步，其实ECDHE算法中服务端需要提供的信息已经结束，发送 Server Hello Done告诉客户端，然后等待客户端回传它的D-H公钥。

算法：

其中p和g是公开的DH参数，只要P是一个足够大的数，在不知道私钥的情况下，即使截获了双方的公钥，也是很难破解的。

客户端收到服务端的证书后，利用信任链检测证书有效性，同时也会同Server Key Exchange 类似，将自己的Diffie-Hellman公钥发送给Server端，

至此，ECDHE协商所需要的信息都传输完毕， 双方都可以基于ECDHE算法算出的共享密钥，同时结合之前的随机数生成最终的对称加密秘钥：

之后客户端发送Change Cipher Spec与 Encrypted Handshake Message标识握手完成，同时传输一个加密的数据给Server，验证双方确立的秘钥是否正确，这就需要服务端也要重复这个操作给客户端，这样才能验证彼此的加解密一致，即服务端也要来一次Encrypted Handshake Message回传给客户端校验，

走完如上流程，双方就确认了正确的对称加密通道，后面就是TLS的数据通信，其Record Layer的ContentType 也会变成 Content Type: Application Data (23)：

最终对称会话密钥包含三部分因子：

Client Hello与Server Hello阶段交换的随机数，是为了提高秘钥的“随机”程度而进行的，这样有助于提高会话密钥破解难度。

HTTPS通过加密与完整性校验可以防止数据包破解与篡改，但对于主动授信的抓包操作是没法防护，比如Charles抓包，在这个场景用户已经风险，并且将Charles提供的证书信任为根证书，这从源头上构建了一条虚拟的信任链：在握手阶段，Charles利用自己的公钥，生成客户端可以信任的篡改证书，从而可以充作中间人进而抓包，所谓中间人攻击，感觉跟Https抓包原理一样，都是要强制添加一个自己的信任根证书。

D. ssl会话建立的过程（原理）是什么

ssl会话建立过程主要就是加密和解密的过程。主要是利用了非对称加密来保证密码的安全，利用签名来保证证书和信息没有被修改。
首先是客户端和服务器端加密技术的沟通，统一后面通信适用的加密技术。
第二步是服务器将自己的身份以证书的方式发送给客户端。同时非对称加密的公钥则是附带在证书的信息中。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被串改。另外，证书还有个有效期。
第三部客户端发送自己的证书给服务器端。
到这里双方完成了非对称加密的key交换。
第四部是证书的验证工作，双方对对方的证书完成验证的工作。同时客户端会使用之前协商好的加密套件和session secret加密一段Finish的数据传送给服务端，此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。
第五部是最后一步，服务端在接收到客户端传过来的PreMaster加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成session secret，一切准备好之后，会给客户端发送一个ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和session secret加密数据了。之后，服务端也会使用session secret加密后一段Finish消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。