公钥私钥证书与https

公钥私钥

非对称加密： 在一个过程中使用两个密钥，公共密钥用于加密信息，私用密钥用于解译加密的信息。这种加密方法称为非对称加密，也称为公钥加密，因为其中一个密钥是公开的（另一个私钥则需要自己保密）。

私钥签名 ：如果我用私钥加密一段数据（当然只有我可以用私钥加密，因为只有我知道我的私钥），结果所有的人都看到我的内容了，因为他们都知道我的公钥，那么这种加密有什么用处呢？但是我的好朋友x说有人冒充我给他发信。怎么办呢？我把我要发的信，内容是c，用我的私钥2，加密，加密后的内容是d，发给x，再告诉他 解密看是不是c。他用我的公钥1解密，发现果然是c。 这个时候，他会想到，能够用我的公钥解密的数据，必然是用我的私钥加的密。只有我知道我得私钥，因此他就可以确认确实是我发的东西。 这样我们就能确认发送方身份了。这个过程叫做数字签名。当然具体的过程要稍微复杂一些。用私钥来加密数据，用途就是数字签名。

数字证书

数字证书： 为了防止中间人攻击，整个传输过程中亟需解决的是保证客户端收到的公钥是服务端发送的，为此提出了数字证书。数字证书可以确保公钥不被冒充。数字证书是经过权威机构（CA）认证的公钥，通过查看数字证书，可以知道该证书是由那家权威机构签发的，证书使用人的信息，使用人的公钥。数字证书是一个经证书授权中心（CA）数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。数字证书还有一个重要的特征就是只在特定的时间段内有效。生成数字证书的流程的如下：

1. 持有人将公钥以及身份信息发送给权威机构。

2. 权威机构负责对持有人的身份进行验证，确保公钥和持有人的信息准确无误。

3. 权威机构使用自己私钥对持有人公钥进行数字签名，生成数字证书。

4. 为了确保证书不被篡改，权威机构对数字证书进行hash计算（指纹算法），生成摘要（指纹），使用自己的私钥对摘要进行数字签名，放到数字证书中。

5. 对持有人收费。

它有以下特点：

1. 由专门的机构签发的数字证书才安全有效。

2. 签发数字证书是收费的。

3. 不会被冒充，安全可信。

4. 数字证书有使用期限，过了使用期限，证书变为不可用。CA也可以在试用期内，对证书进行作废操作。

     接到证书的客户端，可以使用数字证书认证机构的公开密钥，对证书上的数字签名进行验证，一旦验证通过，客户端便明白两件事，一是认证服务器的公开密钥是真实有效的数字证书认证机构。二是服务器的公开密钥是值得信赖的。当客户端发起请求的时候，服务器将该数字证书发送给客户端，客户端将其中的加密密文(F3)通过CA机构提供的公钥及逆行解密后得到F2，同时将证书内容（F1）使用SHA1散列成F2，如果两者相等则说明证书没问题。

总结： 公钥和私钥是成对的，它们互相解密。公钥加密，私钥解密。私钥数字签名，公钥验证。数字证书验证对方公钥的正确合法性。

https与证书

     HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

     HTTPS证书又称SSL证书，是部署在Web服务器中的一张数字证书。部署了HTTPS证书的Web服务器就能对外提供安全可靠的HTTPS服务。用户使用HTTPS协议访问Web网站，可以达到数据加密传输的效果，以保证用户信息传输的安全。非对称加密过程需要用到公钥进行加密，那么公钥从何而来？其实公钥就被包含在数字证书中，数字证书通常来说是由受信任的数字证书颁发机构CA，在验证服务器身份后颁发，证书中包含了一个密钥对（公钥和私钥）和所有者识别信息。数字证书被放到服务端，具有服务器身份验证和数据传输加密功能。这样Web服务器就能够对外提供HTTPS服务了。HTTPS证书产生的整个过程就是如此。

     当用户采用HTTPS协议访问你的网站时，首先会从你的服务器中得到HTTPS证书，然后当用户向Web服务器传输数据时，由于HTTPS证书中已经包含了公钥，所以其实是使用了证书中的公钥对传输数据进行加密，然后把密文发送给Web服务器。Web服务器得到密文后，再使用私钥对密文进行解密，最终得到用户的原文信息。由于用于解密的私钥从始至终都在用户手上，不会被第三者所得到，因此密文信息也不可能被激活成功教程，所以使用HTTPS证书的网站我们都认为是安全可靠的（但前提是私钥不会被泄露）。数字证书内容包括了加密后所保护服务器的公钥、权威机构的信息、服务器域名，有效时间、还有经过CA私钥签名之后的证书内容（经过先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。

     验证证书安全性过程： 服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。当客户端收到这个证书之后，使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过CA公钥解密得到证书信息摘要。然后证书签名的方法计算一下当前证书的信息摘要，与收到的信息摘要作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配。

     示例：client向server发送请求https://baidu.com，然后连接到server的443端口，发送的信息主要是随机值1和客户端支持的加密算法。server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是client发送给server加密算法的子集。随即server给client发送第二个响应报文是数字证书。客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。

会话复用

提高 TLS 握手效率的机制是会话复用。会话复用的原理很简单，将第一次握手辛辛苦苦算出来的对称密钥存起来，后续请求中直接使用。这样可以节省证书传送等开销，也可以将 TLS 握手所需 RTT 减少到一个。

• Session ID重用： Session Identifier（会话标识符），是 TLS 握手中生成的 Session ID。服务端可以将 Session ID 协商后的信息存起来，浏览器也可以保存 Session ID，并在后续的 ClientHello 握手中带上它，如果服务端能找到与之匹配的信息，就可以完成一次快速握手。 对于已经建立的SSL会话，使用session id为key（session id来自第一次请求的server hello中的session id字段），主密钥为value组成一对键值，保存在本地，服务器和客户端都保存一份。当第二次握手时，客户端若想使用会话复用，则发起的client hello中session id会置上对应的值，服务器收到这个client hello，解析session id，查找本地是否有该session id，如果有，判断当前的加密套件和上个会话的加密套件是否一致，一致则允许使用会话复用，于是自己的server hello 中session id也置上和client hello中一样的值。然后计算对称秘钥，解析后续的操作。 如果服务器未查到客户端的session id指定的会话（可能是会话已经老化），则会重新握手，session id要么重新计算（和client hello中session id不一样），要么置成0，这两个方式都会告诉客户端这次会话不进行会话复用。

• Session ticket重用： Session Identifier 机制有一些弊端，例如：1）负载均衡中，多机之间往往没有同步 Session 信息，如果客户端两次请求没有落在同一台机器上就无法找到匹配的信息；2）服务端存储 Session ID 对应的信息不好控制失效时间，太短起不到作用，太长又占用服务端大量资源。而 Session Ticket（会话记录单）可以解决这些问题，Session Ticket 是用只有服务端知道的安全密钥加密过的会话信息，最终保存在浏览器端。浏览器如果在 ClientHello 时带上了 Session Ticket，只要服务器能成功解密就可以完成快速握手。一个会话ticket是一个加密的数据blob，其中包含需要重用的TLS连接信息，如会话key等，它一般是使用ticket key加密，因为ticket key服务器端也知道，在初始握手中服务器发送一个会话ticket到客户端，存储到客户端本地，当重用会话时，客户端发送会话ticket到服务器，服务器解密然后重用会话。

自签名证书

      自签名证书： 自签名证书，就是自己颁发给自己的证书 ，所以颁证的主体是不可信任的。由于我们创建的证书未由您的某个浏览器的受信任证书颁发机构签名，因此您可能会看到一个非安全连接的警告，自签证书是不会被浏览器信任的证书的，用户在访问自签证书时，浏览器会警告用户此证书不受信任，需要人工确认是否信任此证书。实际上此时浏览器已获取到服务器证书server.crt，由于其对应的CA证书不存在于“受信任的根证书机构”中，所以无法验证server.crt。若选择高级选项中的“继续浏览”时，同样可以正常跳转至对应的页面，这时相当于强行让浏览器接受该证书，同时接受服务器公钥。在测试环境下，这样完全OK。服务器证书server.crt是由CA证书的私钥签署的数字证书，若使客户端能验证该证书则我们需要将CA证书（非服务器证书，包含CA证书的公钥-OpenSSL生成的ca.crt）安装至客户端系统中的“受信任的根证书机构”中，保证浏览器可通过此CA证书来验证服务器证书server.crt。

      自签证书用ip不能直接连接https服务器原因由于证书中不存在IP信息，是无法跟URL中的IP进行比对的，因此浏览器无法通过证书验证。自签证书时是签给xxx.xxx.xxx.com域名的，而浏览器中是通过ip访问的，浏览器警告用户证书与所在域不匹配！本机hosts文件中配上映射关系后，使用域名可以访问。或者在证书中添加IP地址。在openssl.cnf中配置使用者可选名称时，添加一条IP地址，即可保证浏览器通过对IP的验证，重新签署。

      在签署证书（server.csr签署ca.crt）之前需要确认openssl.cnf中的配置。openssl.cnf用来进行下一步生成服务器签署申请文件server.csr（openssl req -new -out server.csr -key server.key -config /etc/ssl/openssl.cnf）。

#openssl.cnf的alt_names域中如果没有IP这一项，浏览器使用IP访问时验证无法通过
[ alt_names ]
IP.1 = 192.168.50.115
DNS.1 = dfe.leida.org
DNS.2 = ex.abcexpale.net

参考链接

      正常情况下请不要使用自签名证书,因为如果你直接用自签名证书，你需要给所有的客户端安装该证书才会被信任,而且维护起来也比较麻烦。对于CA机构颁发的证书http默认支持 可以直接访问。但是对于自定义的证书就不可以了， 需要加入Trust。如果是内网用(没用公网域名或只有内网IP)，可以使用 https。单向认证：只需要客户端认证服务端是否正确；双向认证：需要客户端和服务器端互相认证，在单向认证的基础上，服务器也需要认证客户端。在生成证书这一步也需要为客户端生成证书。因为大部分情况下(除比较安全的应用如涉及到支付、银行U盾等)不需要双向认证，所以这里一般单向认证就可以了。客户端安装CA证书(解决浏览器端无法识别证书的问题)。既然自签证书是不可信任的，那为何还有人包括12306也在用自签证书呢？主要原因是：自签证书是免费的 ；自签证书相对申请CA证书，流程更简单 ；自签证书同样可以对数据进行加密 ；自签证书的有效期可以设置很长，免去续签的麻烦 ；自签证书更方便测试，比如说你想生成多少个不同服务器ip的都可以 。