SSL/TLS历史
互联网加密通信协议的历史，几乎与互联网一样长。
- 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
- 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
- 1996年，SSL 3.0版问世，得到大规模应用。
- 1999年，互联网标准化组织ISO接替NetScape公司，发布了SSL的升级版TLS 1.0版。
- 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。
- 最新的变动是2011年TLS 1.2的修订版。
目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。
TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。
运行过程
应用场景
SSL现在应该叫”TLS”,但由于习惯问题,我们还是叫”SSL”比较多。
http协议默认情况下是不加密内容的,这样就很可能在内容传播的时候被别人监听到,对于安全性要求较高的场合,必须要加密。
https就是带加密的http协议,而https的加密是基于SSL的,它执行的是一个比较下层的加密,也就是说,在加密前,你的服务器程序在干嘛,加密后也一样在干嘛,不用动,这个加密对用户和开发者来说都是透明的。
OpenSSL
简单地说,OpenSSL是SSL的一个实现,SSL只是一种规范。
理论上来说,SSL这种规范是安全的,目前的技术水平很难破解,但SSL的实现也有些漏洞,如著名的”心脏出血”。
OpenSSL还提供了一大堆强大的工具软件,强大到90%我们都用不到。
下面会介绍证书相关知识
数字签名：私钥签名公钥验证
基于非对称加密，既可以用于证实某数字内容的完整性，又同时可以确认来源。
一个典型的场景是， Alice 通过信道发给 Bob 一个文件（ 信息）， Bob 如何获知所收到的文件即为 Alice 发出的原始版本？ Alice 可以先对文件内容进行摘要，然后用自己的私钥对摘要进行加密（签名），之后同时将文件和签名都发给 Bob，Bob 收到文件和签名后，用 Alice 的公钥来解密签名，得到数字摘要，与收到文件进行摘要后的结果进行比对，如果一致，说明该文件确实是 Alice 发过来的（别人无法拥有 Alice 的私钥），并且文件内容没有被修改过（摘要结果一致）。
知名的数字签名算法包括 DSA (Digital Signature Algorithm ）和安全强度更高的 ECSDA (Elliptic Curve tal Signature Algorithm ）
数字证书：分发公钥
对于非对称加密算法和数字签名来说，很重要的一点就是公钥的分发。理论上任何人可以公开获取到对方的公钥，然而这个公钥有没有可能是伪造的呢？传输过程中有没有可能被篡改掉呢？公钥自身出了问题，则整个建立在其上的安全体系的安全性将不复存在。
数字证书机制正是为了解决这个问题，它就像日常生活中的一个证书一样，可以证明所记录信息的合法性，比如证明某个公钥是某个实体（如组织或个人）的，并且确保一旦内 容被篡改能被探测出来，从而实现对用户公钥的安全分发。
根据所保护公钥的用途，可以分为加密数字证书（ Encryption Certificate ）和签名验证数字证书（ Signature Certificate ）。前者往往用于保护用于加密信息的公钥； 后者则保护用于进行解密签名进行身份验证的公钥。两种类型的公钥也可以同时放在同一证书中。
一般情况下，证书需要由证书认证机构（ Certification Authority, CA 进行签发和背书。权威的证书认证机构包括 DigiCert、GlobalSign、VeriSign 等。 用户也可以自行搭建本地CA 系统，在私有网络中进行使用。
X.509证书规范
一般来说，一个数字证书内容可能包括基本数据（版本、序列）、 所签名对象信息（签名算法类型、签发者信息、有效期、被签发人、签发的公开密钥）、 CA 的数字签名等等。
目前使用最广泛的标准为 ITU和ISO 联合制定的 X.509 的v3 版本规范，规范中一般推荐使用PEM格式来存储证书文件，该格式采用文本方式进行存储，一般包括首尾标记和内容块，内容块采用 Base64 进行编码，此外还有DER格式，是采用二进制存储，可以与PEM格式互相转换。
SSL使用的就是这种证书标准，其详情可以参考RFC5280。
PKI体系
在非对称加密中，公钥可以通过证书机制来进行保护，但证书的生成、分发、撤销等过程并没有在 X.509 规范中进行定义。PKI 体系核心解决的是证书生命周期相关的认证和管理问题。PKI 是建立在公私钥基础上实现安全可靠传递消息和身份确认的一个通用框架，并不代表某个特定的密码学技术和流程，实现了 PKI 规范的平台可以安全可靠地管理网络中用户的密钥和证书。
一般情况下， PKI 至少包括如下核心组件：
- CA: 负责证书的颁发和作废，接收来自队的请求，是最核心的部分
- RA: 对用户身份进行验证，校验数据合法性，负责登记，审核过了就发给 CA
- 证书数据库：存放证书，多采用 X.500 系列标准格式
证书的签发
CA 对用户签发证书实际上是对某个用户公钥，使用 CA 的私钥对其进行签名，这样任何人都可以用 CA 的公钥对该证书进行合法性验证，验证成功则认可该证书中所提供的用户公钥内容，实现用户公钥的安全分发。
用户证书的签发可以有两种方式。一般可以由 CA 直接来生成证书（内含公钥）和对应的私钥发给用户；也可以由用户自己生成公钥和私钥，然后由 CA 来对公钥内容进行签名。后者情况下，用户一般会首先自行生成一个私钥和证书申请文件（ Certificate Signing Request ，即 csr 文件），该文件中包括了用户对应的公钥和 一些基本信息，如通用名、组织信息、 地理位置等。CA 只需要对证书请求文件进行签名，生成证书文件，颁发给用户即可。整个过程中，用户可以保持私钥信息的私密性，不会被其他方获知（包括 CA 方）。生成证书申请文件的过程并不复杂，用户可以很容易地使用开源软件 openssl 来生成csr 文件和对应的私钥文件。
证书的撤销
证书超出有效期后会作废，用户也可以主动向 CA 申请撤销某证书文件。
由于 CA 无法强制收回已经颁发出去的数字证书，因此为了实现证书的作废，往往还需要维护一个撤销证书列表（ Certificate Revocation List, CRL ），用于记录已经撤销的证书序号。
因此，通常情况下，当第三方对某个证书进行验证时，需要首先检查该证书是否在撤销列表中，如果存在，则该证书无法通过验证，如果不在，则继续进行后续的证书验证过程。
证书编码格式
同样的X.509证书，可以有不同的编码格式，每种编码格式的内容能以多种后缀的文件作为载体存在。
目前主要有pem和der两种编码格式。前者采用文本方式进行存储，一般包括首尾标记和内容块，内容块采用 Base64 进行编码。后者是采用二进制存储，两种格式互相转换。
Apache和Linux服务器偏向于使用pem编码格式。
Java和Windows服务器偏向于使用der编码格式。
pem编码格式的证书文件一般以就以pem后缀结尾，der存在多种后缀的文件，如crt/cer/der等。
OpenSSL操作证书命令
1 | # 查看pem编码格式证书的信息 |
如下操作生成私钥，并通过私有ca自签发证书流程
1 | # 生成私钥 |