简介
Java 和 HTTP 的那些事（四） HTTPS 和 证书
安全的通信有以下要求
- 通信双方可信：是自己人；发了不能抵赖。主要在握手阶段完成。
- 内容不被篡改
- 内容不可见
许式伟：为了彻底阻止木马程序篡改正常的应用程序，聪明的操作系统创造者们想到了好方法：数字签名。这本质上是白名单技术。所有正常发布的软件都到操作系统厂商那里登记一下。这样，一旦木马去修改软件，把自己附加上去（把自己加到一个正常程序的尾部，然后修改程序入口，让它跳转到自己，执行完自己后再跳转回正常的程序代码。这样在用户看来这个程序功能没有发生变化，但是实际上每次开始的时候都会先运行病毒/木马程序再运行正常功能代码。），这个软件的签名验证就通不过，也就直接暴露了。第一个大规模把软件发布变成一个封闭环境的是苹果的 iOS 操作系统。苹果通过引入 App Store，要求所有应用发布都必须通过 App Store 进行。这样一来，软件无法被非法修改，木马基本上就无所遁形了。当然，这并不代表木马在这些平台上就消失了。
受数字签名保护的文档
一个受数字签名保护的文档可示意如下
- “要防篡改的内容” 是信息原文。
- “密钥提示” 是在数字签名的 “密钥” 有多个的情况下，通过 “密钥提示” 找到对应的 “密钥”。如果用于保护信息的 “密钥” 只有一个，那么可以没有 “密钥提示”。
- “指纹” 则是对信息使用特定 “密钥” 和信息摘要算法生成的信息摘要。
为什么需要证书？——安全的分发公钥
包括两部分：TLS 记录协议和 TLS 握手协议。TLS 记录协议主要保证传输过程中信息传输的完整性和私密性，这一部分通过协商后的密钥来加密数据。TLS 握手协议主要是为了认证对方的身份、协商密钥。
数字证书原理逻辑链条：
- 加密由加密算法 + 密钥组成，加密算法公开，于是密钥分发成了关键。（可以试想，若是加密算法私有，自然就没有密钥分发及之后的问题，代之就只加密算法本身的安全问题）
- 对称加密密钥不易分发，也不能每次都一样
- 非对称加密通信，客户端持有服务端的公钥，但服务商的公钥谁都可以得到，服务商给我发的消息，别人虽然不能改，但也可以截获并解密。
- 所以，纯粹的对称加密 和 非对称加密 都是无法做到安全通信的。因此，先使用非对称加密 约定一个对称密钥，再用对称加密交流
-
问题就变成了：客户端如何拿到服务商的公钥？ ==> 服务商的公钥如何安全的在网络上传输呢？==> 服务商不直接分发公钥，而是分发经CA私钥加密过的数字证书（包含公钥+服务商域名等信息）。客户端持有CA的公钥，解密后拿到服务商的公钥。
从概念上来讲，数字证书是用来验证网络通信参与者的一个文件。这和学校颁发 给学生的毕业证书类似。在学校和学生之间，学校是可信第三方 CA，而学生是通信 参与者。如果社会普遍信任一个学校的声誉的话，那么这个学校颁发的毕业证书，也 会得到社会认可。参与者证书和 CA 证书可以类比毕业证和学校的办学许可证。
-
CA的公钥如何安全的在网络上传输呢？给CA 也颁发证书，然后大家都无条件信任root CA，在操作系统、浏览器发布的时候便嵌入了root CA。
就好比谍报战里的接头戏码
- 两个彼此认识的特工接头会轻松一点，双方可能会经常变换下接头方式
- 第一次跟新来的特工接头，上级会告诉你xx点去xx等一个手里拿着xx的人，接头暗号是“hello/world”。此次，双方都认识的上级是CA，“hello/world” 便是对方的CA证书。
证书
-
证书有什么，Chrome可以通过”settings ==> advanced setting ==> https/ssl ==> 管理证书” 查看证书内容。证书基本上是一个文本文件。
- 服务商的公钥
- 服务商的信息
- 对上述信息算一个签名，用ca自己的私钥加密一下
-
如何验证证书？我拥有ca的公钥，对证书上的信息做一个签名， 解密证书上的签名，比对。
- 如果两个签名一样，签名一样，说明证书没被篡改
- 签名可以用ca公钥正确解密，说明是用ca私钥加密的，即证书是ca颁发的
结论，证书是可信的，那么证书上的内容，尤其是服务商的公钥是可信的。就好像，毕业证上学校公章是可信的，那么可以相信这个学生的学历是可信的。
动态加载证书
大多数时候，本地只要有常用的ca根证书，即可验证大部分服务商。证书被验证可信后，浏览器或操作系统会将证书存储在本地（证书有效期内），当用户在浏览器中键入https地址时，直接开始同服务端商定对称算法和密钥，从而省去证书的获取和验证过程。
但是，当服务商证书不在Java 的 cacerts 文件中，或者无法通过ca证书链式推导，我们也可以手动添加。
- 12306之类的网站，证书基本可信，但不是向ca申请的
- 内部通信，证书自己生成，自己确认可信
添加方式
- 使用java keytool工具添加。有时候不具备权限，或要添加的机器过多
- 程序加载。这就是一些应用在使用时，要指定证书地址的缘故了。应用作为客户端，直接加载服务端证书，以省去证书验证过程。
证书的存储
浏览器保存了一个常用的 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，即可绕过对证书的验证。
制作证书
| 文件后缀 | 备注 | |
|---|---|---|
| 证书签名请求(Certificate signing request) | *.csr |
包含域名、国家、城市、公司、邮箱等信息 |
| 私钥(Private Key) | *.key |
|
| 证书(Certificate) | *.cer ,*.crt |
CA 使用其私钥对 csr签名生成crt |
至于pem和der(少见)是编码方式，以上三类（Cert,Key,CSR）均可以使用这两种编码方式。
*.pem- base64编码*.der- 二进制编码
假设自己的nginx 对外提供https支持
- 自建ca 或第三方ca 机构
- 在nginx 机器上 创建一对儿rsa密钥（key文件）；生成证书请求（csr文件）
- 将csr文件发送到ca服务器（第三方ca机构），得到nginx crt证书（crt或pem后缀）
- 访问nginx 的客户端持有ca 根crt证书，持有或获取 nginx 的crt 证书，即可与nginx 进行https通讯。
ca和pki
- 基于私钥加密，只能使用公钥解密：起到身份认证的作用。
- 公钥的管理：PKI 公钥基础设施
- 由CA 数字证书认证机构将用户个人身份与公开秘钥关联在一起。 PS：就好像微博认证xx 账号是xx，所以我们可以相信xx账号发的内容是xx 发的。
- 公钥数字证书组成：CA信息、公钥用户信息、公钥、权威结构的签字、有效期。
所以呢，有一个PKI（Public Key Infrastructure）的概念，中文称作公钥基础设施。它提供公钥加密和数字签名服务的系统或平台，比如ca系统，浏览器和操作系统内置一些常用ca证书。通过协议和机制的约定，实现公钥的可信分发，进而建立起一个安全的网络环境。而数字证书最常见的格式是 X.509 ，所以这种公钥基础设施又称之为 PKIX 。
而在大公司内部，通常会建立私有的ca和pki体系。
安全应用
ssh
密码登陆
如果嫌每次登陆输密码麻烦，可以公钥登陆
https
SSL/TLS 四次握手
总结一下https设计到的一些加密知识
- 哈希，将任意长度的数据转化为固定长度的，验证数据是否被篡改
- 对称加密，加密和解密使用同一个密钥，对称加密的优点是速度快，缺点是密钥管理不方便，必须共享密钥
- 非对称加密，缺点是速度慢，优点是双方无需共享同一个密钥，密钥管理很方便
- 数字证书，提供可信的服务商公钥
其它
上文提到的都是单向非对称加密，对于安全性很高的场景（比如网银）， 不仅客户端要验证服务端的合法性，服务端也要验证每个访问的客户端的合法性，对于这种场景，往往给每个用户发一个U盘，里面装的就是客户端的公钥和私钥对，用于双向非对称加密。