内容简介：ssl证书是什么东西
简介
Java 和 HTTP 的那些事（四） HTTPS 和 证书
加密
总结一下https设计到的一些加密知识
- 哈希，将任意长度的数据转化为固定长度的，验证数据是否被篡改
- 对称加密，加密和解密使用同一个密钥，对称加密的优点是速度快，缺点是密钥管理不方便，必须共享密钥
- 非对称加密，缺点是速度慢，优点是密钥管理很方便
- 数字证书，提供可信的服务商公钥
安全的通信有以下要求
- 通信双方可信
- 内容不被篡改
- 内容不可见
证书
| 私钥 | 公钥 | |
|---|---|---|
| ca | 一般浏览器安装时就有，存在ca根证书中 | |
| 服务商 | 浏览器验证服务商证书有效后，从服务商证书中拿到服务商公钥 |
-
证书有什么，Chrome可以通过”settings ==> advanced setting ==> https/ssl ==> 管理证书” 查看证书内容。证书基本上是一个文本文件。
- 服务商的公钥
- 服务商的信息
- 对上述信息算一个签名，用ca自己的私钥加密一下
-
我如何验证证书？我拥有ca的公钥，对证书上的信息做一个签名， 解密证书上的签名，比对。
- 如果两个签名一样，签名一样，说明证书没被篡改
- 签名可以用ca公钥正确解密，说明是用ca私钥加密的，即证书是ca颁发的
结论，证书是可信的，那么证书上的内容，尤其是服务商的公钥是可信的。
逻辑链条：
- 首先，我要知道服务商是不是可信的
- 为了验证服务商的身份，要知道服务商的公钥。服务商发来的数据用公钥可以解密，说明服务商是可信的。前提：服务商私钥没泄漏；拿到的服务商公钥是可信的。
- 需要一个可信的服务商公钥，找服务商要么？
- 本地存有ca的公钥（绝对可惜），服务商那有ca给的证明，那服务商别给我公钥了（我也不知道真的假的），给我ca的证明吧（里面有服务商的公钥）。 这个ca的证明，就是为了提供可信的服务商公钥。
- 浏览器会尝试查CRL(证书吊销列表)和OCSP(在线证书检查)，后者是前者的替代，即直接询问ca证书是否可信及在有效期内。但ca都在国外， 因为证书不可篡改，所以谁给都一样 (这一步待确认)
- 服务商可信了，但服务商的公钥谁都可以得到，服务商给我发的消息，别人虽然不能改，但也可以截获并解密。
- 我另搞一套对称加密，加密算法和密钥用服务商公钥加密，发给服务商，只有服务商的私钥才可以解密
- 大家从此用对称加密交流
证书的存储
浏览器保存了一个常用的 CA 证书列表，与此类似的，操作系统也一样保存有一份可信的证书列表。Java 在 JRE 的安装目录下也保存了一份默认可信的证书列表，可以使用 JRE 自带的 keytool 工具.
/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/security --- cacerts
证书的格式
CA 在发布证书时，常常使用 PEM 格式，这种格式的好处是纯文本，内容是 BASE64 编码的，另外还有比较常用的二进制 DER 格式，在 Windows 平台上较常使用的 PKCS#12 格式等等。当然，不同格式的证书之间是可以相互转换的。
在 Java 平台下，证书常常被存储在 KeyStore 文件中，上面说的 cacerts 文件就是一个 KeyStore 文件（KeyStore 只是一种文件格式，java中使用keyStore文件存储加密相关的数据，证书是其中一种）。存储在 KeyStore 文件中的对象有三种类型：Certificate、PrivateKey 和 SecretKey 。Certificate 就是证书，PrivateKey 是非对称加密中的私钥，SecretKey 用于对称加密，是对称加密中的密钥。
KeyStore 文件根据用途，也有很多种不同的格式：JKS、JCEKS、PKCS12、DKS 等等。
java中的keyStore文件根据用途，分为两类：keyStore、TrustStore，对应两个类 KeyManager 和 TrustManager。前者负责管理自己的私钥等数据，后者负责存储一些可信任的证书。可以想见，如果我们改写 TrustManager 类，让其无论何时都返回true，即可绕过对证书的验证。
动态加载证书
大多数时候，本地只要有常用的ca根证书，即可验证大部分服务商。证书被验证可信后，浏览器或操作系统会将证书存储在本地（证书有效期内），当用户在浏览器中键入https地址时，直接开始同服务端商定对称算法和密钥，从而省去证书的获取和验证过程。
但是，当服务商证书不在Java 的 cacerts 文件中，或者无法通过ca证书链式推导，我们也可以手动添加。
- 12306之类的网站，证书基本可信，但不是向ca申请的
- 内部通信，证书自己生成，自己确认可信
添加方式
- 使用java keytool工具添加。有时候不具备权限，或要添加的机器过多
- 程序加载
这就是一些应用在使用时，要指定证书地址的缘故了。
- 应用作为服务端，client索要证书时，提供给client
- 应用作为客户端，直接加载服务端证书，以省去证书验证过程
ca和pki
所以呢，有一个PKI（Public Key Infrastructure）的概念，中文称作公钥基础设施。它提供公钥加密和数字签名服务的系统或平台，比如ca系统，浏览器和操作系统内置一些常用ca证书。通过协议和机制的约定，实现公钥的可信分发，进而建立起一个安全的网络环境。而数字证书最常见的格式是 X.509 ，所以这种公钥基础设施又称之为 PKIX 。
而在大公司内部，通常会建立私有的ca和pki体系。
根据tls的通信流程，如果内网的节点要彼此tls访问，且需双向验证，则
- 有一个私有的ca服务器
- 生成一对儿ca公钥私钥对，根据ca公钥生成一个ca证书
- 为每一个节点，生成公钥私钥对，基于ca证书生成对应节点证书
- 每个节点保有一份儿ca证书
tls通信过程中，节点作为服务端，则会分发自己的证书。作为客户端，则会索要服务端证书，并基于本机的ca证书进行验证。还有一种方案，每个节点不保有ca证书，而是直接保有其它节点的ca证书。实例参见 Docker Swarm中使用TLS
安装过hadoop的同学都知道，有一个过程是，将所有slave节点的公钥交给master节点，这里slave节点类似于服务端，master节点类似于客户端。只是hadoop分发的是公钥，tls分发的是证书（分发证书也是为了分发公钥）。
以上所述就是小编给大家介绍的《ssl证书是什么东西》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
