HTTPS中CA证书的签发及使用过程

Posted 2021-05-07 xdyixia

1，HTTPS

简单来讲，HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议就是安全的HTTP，我们知道HTTP是运行在TCP层之上的，HTTPS在HTTP层和TCP层之间加了一个SSL层，SSL向上提供加密和解密的服务，对HTTP比较透明，这样也便于服务器和客户端的实现以及升级。

HTTP是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准(TCP)，用于从WWW服务器传输超文本到本地浏览器的传输协议。HTTP是采用明文形式进行数据传输，极易被不法份子窃取和篡改。

HTTPS为什么安全？

HTTPS安全是由一套安全机制来保证的，主要包含这4个特性：机密性、完整性、真实性和不可否认性。 

• 机密性是指传输的数据是采用Session Key（会话密钥）加密的，在网络上是看不到明文的。
• 完整性是指为了避免网络中传输的数据被非法篡改，使用MAC算法来保证消息的完整性。
• 真实性是指通信的对方是可信的，利用了PKI（Public Key Infrastructure 即『公钥基础设施』）来保证公钥的真实性。
• 不可否认性是这个消息就是你给我发的，无法伪装和否认，是因为使用了签名的技术来保证的。

2，TLS/SSL

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

 

散列函数Hash

　　常见的有 MD5、SHA1、SHA256，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性;
　　在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密;

对称加密和非对称加密

对称加密是一把密钥，这把密钥可以加密明文，也可以解密加密后的密文，常见的对称加密算法有AES、DES、RC4，目前最常用的是AES。

非对称加密是两把密钥，分别是公钥和私钥，公钥加密的密文只有相对应的私钥才能解密，私钥加密的内容也只有相对应的公钥才能解密，其中公钥是公开的，私钥是自己保存，不能公开，常见的非对称加密算法有RSA和ECC（椭圆曲线算法）。

SSL结合了这两种加密算法的优点，通过非对称加密来协商对称加密的密钥，握手成功之后便可使用对称加密来做加密通信，对于RSA来说，客户端是用RSA的公钥把预主密钥加密后传给服务器，服务器再用私钥来解密，双方再通过相同的算法来生成会话密钥，之后的应用层数据就可以通过会话密钥来加密通信。

签名

SSL中还有一个使用非对称加密的地方就是签名，签名的目的是让对方相信这个数据是我发送的，而不是其他人发送的。

密钥安全强度与性能对比

加密之后的数据破解难度就体现在密钥的长度上，密钥越长，破解难度也越大，但是运算的时间也越长，性能也就越差。相同安全强度下，对称密钥长度在最短，ECC次之，RSA密钥长度则最长。

目前比较常用的密钥长度是：对称密钥128位、ECC 256位、RSA 2048位。

RSA和ECC在SSL中更多的是用来签名，通过测试发现，ECC 的签名性能比RSA好很多，但是RSA的验签性能比ECC更好，所以RSA更适合于验证签名频繁而签名频度较低的场景，ECC更适合于签名频繁的场景，在SSL场景中，ECC算法性能更好。

3，公钥基础设施（PKI）

公钥基础设施的必要性

身份验证和密钥协商是TLS的基础功能，要求的前提是合法的服务器掌握着对应的私钥，但无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，存在安全隐患:

1）中间人攻击： 

    客户端C和服务器S进行通信，中间节点M截获了二者的通信;
    节点M自己计算产生一对公钥pub_M和私钥pri_M;
    C向S请求公钥时，M把自己的公钥pub_M发给了C;
    C使用公钥 pub_M加密的数据能够被M解密，因为M掌握对应的私钥pri_M，而 C无法根据公钥信息判断服务器的身份，从而 C和 M之间建立了"可信"加密连接;
    中间节点M和服务器S之间再建立合法的连接，因此 C和 S之间通信被M完全掌握，M可以进行信息的窃听、篡改等操作。

2）信息抵赖

　服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。

证书颁发机构CA

　　解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA。简单的说，PKI就是浏览器和CA，CA是整个安全机制的重要保障，我们平时用的证书就是由CA机构颁发，其实就是用CA的私钥给用户的证书签名，然后在证书的签名字段中填充这个签名值，浏览器在验证这个证书的时候就是使用CA的公钥进行验签。

CA使用的具体流程：

    a.服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;（不交私钥）
    b.CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
    c.如信息审核通过，CA会向申请者签发认证文件-证书。
       证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名;
       签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名;
    d.客户端 C 向服务器 S 发出请求时，S 返回证书文件;
    e.客户端 C读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法;
    f.客户端然后验证证书相关的域名信息、有效时间等信息;
    g.客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

在这个过程注意几点：
    a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握;
    b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;
    c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）
    d.证书=公钥（服务方生成密码对中的公钥）+申请者与颁发者信息+签名（用CA机构生成的密码对的私钥进行签名）;

即便有人截取服务器A证书，再发给客户端，想冒充服务器A，也无法实现。因为证书和url的域名是绑定的。

CA的作用：

1）颁发证书，颁发证书其实就是使用CA的私钥对证书请求签名文件进行签名；

2）颁发的证书浏览器要信任，浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的，这就需要浏览器内置CA的公钥，也就是内置CA的证书。一般来说，操作系统都会内置权威CA的证书，有的浏览器会使用操作系统内置的CA证书列表，有的浏览器则自己维护的CA证书列表，比如Firefox。

证书链

 如 CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。
    a.服务器证书 server.pem 的签发者为中间证书机构 inter，inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书;
    b.中间证书 inter.pem 的签发 CA 为 root，root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书;
    c.客户端内置信任 CA 的 root.pem 证书，因此服务器证书 server.pem 的被信任。

服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。
二级证书结构存在的优势：
    a.减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;
    b.根证书一般内置在客户端（浏览器或操作系统）中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;
    c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;
    d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。

证书链有以下特点：
    a.同一本服务器证书可能存在多条合法的证书链。
    因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;
    b.不同证书链的层级不一定相同，可能二级、三级或四级证书链。
    中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。

交叉证书

交叉证书的应用场景是这样的：假如现在阿里云成为一个新的根CA机构，那阿里云签发的证书想要浏览器信任的话，阿里云的根证书就需要内置在各大操作系统和浏览器中，这需要较长时间的部署，那在没有完全部署完成之前，阿里云签发的证书怎么才能让浏览器信任呢，这就需要用到交叉证书了。

上图中，根证书A是一个所有浏览器都内置了的根证书，B是一个新的根证书，用户证书D是由根证书 B的二级CA B1来签发的，但是根证书B并没有在浏览器中内置，所以浏览器不会信任用户证书D，这是因为浏览器在验签时只验证到B1这一层然后找不到根证书B就无法验证下去了。

如果二级CA B1证书是由根证书A来签名，那这个问题就解了，所以新的根证书机构B会将二级CA证书（准确地讲是二级CA的证书签名请求文件）给老的根证书A来签名，然后得到一个新的中间证书就是交叉证书。

浏览器在验证的时侯用了新的信任链，这样就可以解决用户证书的信任问题。

当B的根证书全部部署完成后，再替换成自己的二级CA就可以了。

证书分类

证书分有三类：DV、OV、EV

DV证书只校验域名的所有权，所以我们在申请DV证书的时候CA会提供几种验证域名所有权的方法：比如文件校验、DNS校验、邮件校验，DV证书支持单域名、多域名和泛域名，但不支持多个泛域名，只支持一个泛域名，一般价格比较便宜，具体价格跟域名的数量有关，域名越多价格越高。

OV证书要验证组织机构，在申请证书时CA会打电话确认这个域名是否真的属于相应的公司或者机构，OV证书是单域名、多域名、泛域名和多个泛域名都支持，价格一般比DV证书要贵。

EV证书的校验就更细了，比如组织机构的地址之类的，EV证书会在地址栏上显示组织机构的名称，EV证书只支持单域名或者多个域名，不支持泛域名，而且更贵，所以普通用户一般不会用EV证书。

证书吊销

证书是有生命周期的，如果证书的私钥泄漏了那这个证书就得吊销，一般有两种吊销方式：CRL和OCSP。

CRL（ Certificate Revocation List）是CA机构维护的一个已经被吊销的证书序列号列表，浏览器需要定时更新这个列表，浏览器在验证证书合法性的时候也会在证书吊销列表中查询是否已经被吊销，如果被吊销了那这个证书也是不可信的。可以看出，这个列表随着被吊销证书的增加而增加，列表会越来越大，浏览器还需要定时更新，实时性也比较差。

所以，后来就有了 OCSP （Online Certificate Status Protocol）在线证书状态协议，这个协议就是解决了 CRL 列表越来越大和实时性差的问题而生的。有了这个协议，浏览器就可以不用定期更新CRL了，在验证证书的时候直接去CA服务器实时校验一下证书有没有被吊销就可以，是解决了CRL的问题，但是每次都要去CA服务器上校验也会很慢，在网络环境较差的时候或者跨国访问的时候，体验就非常差了，OCSP虽然解决了CRL的问题但是性能却很差。

主要摘自 

http://www.360doc.com/content/18/0606/20/13644263_760231690.shtml 

https://blog.csdn.net/hherima/article/details/52469360

https://blog.csdn.net/hherima/article/details/52469488