HTTPS和证书原理

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/liweisnake/article/details/40074321

  安全的原理其实非常多，基础的诸如数字签名，加密解密等等，这边不会细讲，会略微提一下。主要讲讲常见的web相关的安全原理，比如HTTPS，证书，双向证书等。

  关于对称加密和非对称加密：对称加密算法比非对称加密要快，但是对称加密要求密钥对等，这会带来几个问题：一是密钥传输过程中容易被截获，从而导致加密的无效；二是在一个n节点的传输网络中，某节点需要保存n-1个密钥，非常繁琐。非对称加密则不存在这个问题，于是被广泛的应用于各种传输场景，而非对称加密有很多好处，比如加解密和签名验签，应用非对称的方式，避免了对称带来的问题，当然，性能上就得牺牲了。

  关于加解密和签名验签：最初很难分清到底是公钥加密私钥解密，还是公钥签名私钥验签，亦或是反过来。实际上是公钥加密私钥解密，私钥签名公钥验签，如何理解这个过程呢，如果说换成公钥签名私钥验签会发生什么事？如图，机构A持有私钥，B,C,D,E都持有机构A的公钥，现在B发送一个消息给A，使用公钥签名，A能够通过这个签名证明是B发来的消息吗？显然不行，因为也有可能是持有同样公钥的C,D,E发来的。所以公钥签名私钥验签实际上不成立。可以参考数字签名是什么？

  HTTPS的协商过程：HTTPS的协商目的主要是基于使用非对称加密做传输会拖慢速度，因而客户端和服务器端首先需要基于非对称加密协商出一个对称加密的key。所以简化过的HTTPS的协商流程是这样的。

  1. 浏览器首先向服务器发起请求

  2. 服务器响应浏览器，并将自己的证书传递给浏览器，浏览器从证书得到公钥

  3. 浏览器生成sessionKey，这个key今后会被用来用作对称加密，浏览器用证书中的公钥加密这个sessionKey并发送到服务器

  4. 服务器使用自身私钥解密出sessionKey

  5. 后续的传输只需要建立在http上，双方都使用这个sessionKey做对称加解密就能完成整个通信

  这个过程是简化后的，实际上握手的过程还会传输SSL版本，随机数，加密方法，压缩方法等等，sessionKey的生成也有所不同。但总体思路大致如此。

  更多请参考SSL/TLS协议运行机制的概述, 数字证书原理

  证书：直观的看，证书包括以下这些内容：

  1. 证书序列号

  2. 证书过期时间

  3. 站点组织名

  4. 站点DNS主机名

  5. 站点公钥

  6. 证书颁发者名

  7. 证书签名

  PKCS 全称是 Public-Key Cryptography Standards ，是由 RSA 实验室与其它安全系统开发商为促进公钥密码的发展而制订的一系列标准，PKCS 目前共发布过 15 个标准。常用的有：
  PKCS#7 Cryptographic Message Syntax Standard,.P7B .P7C(证书链) .SPC .P7R(证书请求回复)
  PKCS#10 Certification Request Standard, .P10(用作证书请求)
  PKCS#12 Personal Information Exchange Syntax Standard,.P12 .PFX(二进制形式，公私钥，保护密码)

  X.509是常见通用的证书格式。所有的证书都符合为Public Key Infrastructure (PKI) 制定的 ITU-T X509 国际标准。

  X.509 DER 编码(ASCII), .DER .CER .CRT(二进制，只含公钥)
  X.509 PEM 编码(Base64), .PEM(BASE64，只含公钥，以-----BEGIN CERTIFICATE-----开头) .CER .CRT

  证书链：证书链的出现，其本质是因为如果证书颁发机构过多的话，不容易识别，防伪和管理，于是形成了少数几家国际权威的证书颁发机构，这些机构非常权威，默认是所有人都可信的，它们成为根证书。但是除了这些机构外，其他的机构也需要被信任，因而，需要这些权威的机构去授信颁发证书，于是就形成了一级证书机构，一级证书机构又可以继续授信下级机构，于是成为树状结构，对于任何一个组织到根证书就是链状结构。

  如图：假设你想要成为一个受信任的网站或机构，只需要找你的上级机构去颁发证书给你，颁发时你将自己的公钥，host等信息发送到颁发机构，该机构会将自己的证书附上你的信息，并用自己的私钥签名，做成一张新的证书发给你；而这个上级机构他的证书又是同样的方法由CA颁发的。

  那么，其他人怎么确认你的证书是合法的呢。首先你的证书会在https握手过程中被传递到浏览器，浏览器从你的证书中找到了颁发者，从颁发者的证书（如果你电脑上有的话）又找到了CA的证书（CA证书会在操作系统安装时就安装好，所以每个人电脑上都有根证书），使用CA证书中带的公钥来对颁发者证书做验签，一旦匹配，说明你电脑上的颁发者证书不是伪造的，同理，再用颁发者证书中的公钥去验证你的证书，以此证明你的证书不是伪造的。这样整个链状的验证，从而确保你的证书一定是直接或间接从CA签发的，这样浏览器地址栏会显示一个绿色的盾牌，表示你的网站能通过证书验证

  如果你的电脑上没有颁发者证书（断链）或者你自己本身就是自签名证书（自己做CA，但是要记得，人家电脑上并没有装你的自签名根证书），那么浏览器会报警提示不能验证证书，问你是否还需要继续。

使用ssh生成RSA证书

使用openssl生成RSA证书 http://blog.csdn.net/jiangsq12345/article/details/6066275

java：如何生成以及导入x.509证书  http://blog.sina.com.cn/s/blog_6e1c7b590101mr3p.html

关于PKCS#7与PKCS#5标准的区别：