openssl——自签名根证书、签名客户端和服务器证书

openssl genrsa -out root.key 2048

也可以是pem文件，也可为了区分这是私钥而改用key后缀名，内容如下：

查看详细解析：包含两个大素数和两个指数和一个系数

openssl rsa -in root.key -text

可通过命令提取公钥：

openssl rsa -pubout -in root.key

openssl req -new -out root-req.csr -key root.key -keyform PEM

-keyform PEM：证书有pem和der格式之分，前者文本，多用于java和windows服务器，后者二进制

CSR是Certificate Signing Request的英文缩写，即证书请求文件

openssl x509 -req -in root-req.csr -out root-cert.cer -signkey root.key -CAcreateserial -days 365

-CAcreateserial ，创建证书序列号，使用此选项，当CA序列号文件不存在时将被创建：它将包含序列号“02”，正在签名的证书将具有1作为其序列号。通常如果指定了-CA选项并且序列号文件不存在，则会出现错误。

-days 据说3650天有时候会意外导致证书验证失败，没遇到过

此处可有pem、crt、cer多种输出格式，其实内容都一样，来试一下：

每次生成的证书都不一样，但是未发现不同后缀名下的证书格式不同。

我的理解：

pem是最基本的编码格式，der也相同。

CRT文件是由第三方证书颁发机构（例如VeriSign或DigiCert）提供和生成的安全文件，ASCII编码格式。

cer是crt的微软形式。

为了统一，全使用cer格式。

可选择将证书和私钥导入密钥库，通常用p12和jks（ Java Key Store）格式：

openssl pkcs12 -export -in root-cert.cer -inkey root.key -out root.p12 -name "lab"

需要加密保护， -name 设置别名

然后可选择使用keytool将p12转为jks格式，此处就不做转换了。

步骤基本相同

步骤基本相同

openssl genrsa -out server-key.key 2048

openssl req -new -out server-req.csr -key server-key.key -keyform PEM

openssl x509 -req -in server-req.csr -out server-cert.cer -CA F:\CERT\mycert\ test\openssl\win\root\root-cert.cer -CAkey F:\CERT\mycert\test\openssl\win\root\root.key -CAcreateserial -days 360

openssl pkcs12 -export -in server-cert.cer -inkey server-key.key -out server. p12 -name "lab-server"

运行环境要包含完整证书链。需要将证书链放到系统可信目录下。

为证书绑定ip，只能通过config文件，

文件如下【可将常用参数写入，生成请求文件时直接enter即可】：

使用配置文件时在生成请求文件和签发证书时的参数不同：

生成请求文件：

openssl req -new -out server-req1.csr -key server-key.key -keyform PEM -extensions v3_req -config openssl. cnf

签发证书：

openssl x509 -req -in server-req1.csr -out server-cert1.cer -CA F:\CERT\mycert\test\openssl\win\root\root- cert.cer -CAkey F:\CERT\mycert\test\openssl\win\root\root.key -CAcreateserial -days 360 -extensions v3_req -extfile openssl.cnf

默认证书链长度为2，使用中间ca签发时，中间ca的生成需要在配置文件中加修改长度参数：

[ v3_ca ]

basicConstraints = CA:true,pathlen:3

Note：

参考：

OpenSSL主配置文件openssl.cnf

利用OpenSSL创建证书链并应用于IIS7

openssl系列文章： http://www.cnblogs.com/f-ck-need-u/p/7048359.html

TLS/SSL的功能实现主要依赖于 三类基本算法 ： 散列（哈希）函数 Hash 、 对称加密 和 非对称加密 ，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列（哈希）函数验证信息的完整性。

TCP握手建立链接后，客户端向服务端发送https请求前要握手一次，主要是认证服务端是否可信，与服务端协商后续传输数据的加密方式，以及校验完整性的签名方式（HASH）

解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA。简单的说，PKI就是浏览器和CA，CA是整个安全机制的重要保障，我们平时用的证书就是由CA机构颁发，其实就是 用CA的私钥给用户的证书签名 ，然后在证书的签名字段中填充这个签名值，浏览器在验证这个证书的时候就是使用CA的公钥进行验签。

在这个过程注意几点：

a.申请证书不需要提供私钥， 确保私钥永远只能服务器掌握

b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名

c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）

d. 证书=公钥（服务方生成密码对中的公钥）+申请者与颁发者信息+签名（用CA机构生成的密码对的私钥进行签名）

即便有人截取服务器A证书，再发给客户端，想冒充服务器A，也无法实现。因为证书和url的域名是绑定的。

1）颁发证书，颁发证书其实就是使用CA的私钥对证书请求签名文件进行签名；

2）颁发的证书浏览器要信任，浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的，这就需要浏览器内置CA的公钥，也就是内置CA的证书。一般来说，操作系统都会内置权威CA的证书，有的浏览器会使用操作系统内置的CA证书列表，有的浏览器则自己维护的CA证书列表，比如Firefox。

如 CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。

a.服务器证书 server.pem 的签发者为中间证书机构 inter，inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书

b.中间证书 inter.pem 的签发 CA 为 root，root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书

c.客户端内置信任 CA 的 root.pem 证书，因此服务器证书 server.pem 的被信任。

服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。

二级证书结构存在的优势：

a.减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发

b .根证书一般内置在客户端（浏览器或操作系统）中 ，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救

c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书

d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。

证书链有以下特点：

a.同一本服务器证书可能存在多条合法的证书链。

因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同

b.不同证书链的层级不一定相同，可能二级、三级或四级证书链。

中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。

交叉证书的应用场景是这样的：假如现在阿里云成为一个新的根CA机构，那阿里云签发的证书想要浏览器信任的话，阿里云的根证书就需要内置在各大操作系统和浏览器中，这需要较长时间的部署，那在没有完全部署完成之前，阿里云签发的证书怎么才能让浏览器信任呢，这就需要用到交叉证书了。

上图中，根证书A是一个所有浏览器都内置了的根证书，B是一个新的根证书，用户证书D是由根证书 B的二级CA B1来签发的，但是根证书B并没有在浏览器中内置，所以浏览器不会信任用户证书D，这是因为浏览器在验签时只验证到B1这一层然后找不到根证书B就无法验证下去了。

如果二级CA B1证书是由根证书A来签名，那这个问题就解了，所以新的根证书机构B会将二级CA证书（准确地讲是二级CA的证书签名请求文件）给老的根证书A来签名，然后得到一个新的中间证书就是交叉证书。

浏览器在验证的时侯用了新的信任链，这样就可以解决用户证书的信任问题。

当B的根证书全部部署完成后，再替换成自己的二级CA就可以了。

证书分有三类：DV、OV、EV

DV证书只校验域名的所有权，所以我们在申请DV证书的时候CA会提供几种验证域名所有权的方法：比如文件校验、DNS校验、邮件校验，DV证书支持单域名、多域名和泛域名，但不支持多个泛域名，只支持一个泛域名，一般价格比较便宜，具体价格跟域名的数量有关，域名越多价格越高。

OV证书要验证组织机构，在申请证书时CA会打电话确认这个域名是否真的属于相应的公司或者机构，OV证书是单域名、多域名、泛域名和多个泛域名都支持，价格一般比DV证书要贵。

EV证书的校验就更细了，比如组织机构的地址之类的，EV证书会在地址栏上显示组织机构的名称，EV证书只支持单域名或者多个域名，不支持泛域名，而且更贵，所以普通用户一般不会用EV证书。

证书是有生命周期的，如果证书的私钥泄漏了那这个证书就得吊销，一般有两种吊销方式：CRL和OCSP。

CRL（ Certificate Revocation List）是CA机构维护的一个已经被吊销的证书序列号列表，浏览器需要定时更新这个列表，浏览器在验证证书合法性的时候也会在证书吊销列表中查询是否已经被吊销，如果被吊销了那这个证书也是不可信的。可以看出，这个列表随着被吊销证书的增加而增加，列表会越来越大，浏览器还需要定时更新，实时性也比较差。

所以，后来就有了 OCSP （Online Certificate Status Protocol）在线证书状态协议，这个协议就是解决了 CRL 列表越来越大和实时性差的问题而生的。有了这个协议，浏览器就可以不用定期更新CRL了，在验证证书的时候直接去CA服务器实时校验一下证书有没有被吊销就可以，是解决了CRL的问题，但是每次都要去CA服务器上校验也会很慢，在网络环境较差的时候或者跨国访问的时候，体验就非常差了，OCSP虽然解决了CRL的问题但是性能却很差。

主要摘自

http://www.360doc.com/content/18/0606/20/13644263_760231690.shtml

https://blog.csdn.net/hherima/article/details/52469360

https://blog.csdn.net/hherima/article/details/52469488

让我们花几分钟时间讨论一下中间证书和根CA证书。SSL(或者更准确地说，TLS)是一项大多数终端用户知之甚少甚至一无所知的技术。即使是获取了SSL证书的人通常也只知道他们需要SSL证书，而且他们必须在服务器上安装SSL证书，才能通过HTTPS为网站提供服务。当提到中间证书和CAs、根证书和CAs时，大多数人的目光开始变得呆滞。

在进一步讨论之前，我们需要先引入证书链的概念。提一个问题:您的浏览器如何知道是否应该信任网站的SSL证书? 受信任的根的任何下级证书都是受信任的。这在技术层面上是如何工作的呢?

当你访问一个网站时，浏览器会查看它的SSL证书，并快速的验证证书的真实性。浏览器会检查证书的有效期、确保证书没有被撤销、验证证书的数字签名。

浏览器循着证书链对证书进行身份验证的操作。要获得颁发的SSL证书，首先要生成证书签名请求(CSR)和私钥。最简单的迭代，你将CSR发送给证书颁发机构，然后它使用来自其根的私钥签署SSL证书并将其发送回来。

现在，当浏览器看到SSL证书时，它会看到证书是由其根存储中的一个受信任根颁发的(或者更准确地说，使用根的私钥签名)。因为它信任根，所以它信任根签名的任何证书。为了使你更容易理解，上述内容我们作了简化，将服务器证书直接链到根。现在加入中间证书。

证书颁发机构不会直接从它们的根证书颁发服务器/叶子证书(最终用户SSL证书)。这些根证书太宝贵了，直接颁发风险太大了。

因此，为了保护根证书，CAs通常会颁发所谓的中间根。CA使用它的私钥对中间根签名，使它受到信任。然后CA使用中间证书的私钥签署和颁发终端用户SSL证书。这个过程可以执行多次，其中一个中间根对另一个中间根进行签名，然后CA使用该根对证书进行签名。这些链接，从根到中间到叶子，都是证书链。下面是证书链的可视化图形，为了便于理解，简化复杂的过程，我们只在证书链中加入一个中间证书，实际的证书链通常要复杂得多。

你可能会注意到，当CA颁发SSL证书时，它还会发送需要安装的中间证书。这样，浏览器就能够完成证书链，并将服务器上的SSL证书链接回它的一个根。浏览器和操作系统处理不完整链的方式各不相同。有些只会在中间证书丢失时发出问题并报错，而另一些则会保存和缓存中间证书，以防它们日后派上用场。

数字签名有点像数字形式的公证。当根证书对中间证书进行数字签名时，它实际上是将部分信任转移给中间证书。因为签名直接来自受信任根证书的私钥，所以它是自动受信任的。

任何时候，只要向浏览器或设备提供SSL证书，它就会接收证书以及与证书关联的公钥。它通过公钥验证数字签名，并查看它是由谁生成的（即由哪个证书签名的）。你现在可以开始把这些拼凑起来。当您的浏览器在网站上验证最终用户SSL证书时，它使用提供的公钥来验证签名并在证书链上向上移动一个链接。重复这个过程：对签名进行身份验证，并跟踪签名的证书链，直到最终到达浏览器信任存储中的一个根证书。如果它不能将证书链回其受信任的根，它就不会信任该证书。

这其实很简单。Root CA（根CA）是拥有一个或多个可信根的证书颁发机构。这意味着它们根植于主流浏览器的信任存储中。中间CAs或子CAs是由中间根发出的证书颁发机构。 它们在浏览器的信任存储中没有根，它们的中间根会链回到一个受信任的第三方根。这有时称为交叉签名。

正如我们前面讨论的，CA并不直接从它们的根颁发证书。他们通过颁发中间证书并使用中间证书签署证书，增加根证书的安全性。这有助于在发生误发或安全事件时最小化和划分损害，当安全事件发生时，不需要撤销根证书，只需撤销中间证书，使从该中间证书发出的证书组不受信任。

我们刚描述了根和中间体，涉及到证书颁发机构、证书链和加密签名的信任模型，本质上归结到一个词：PKI或公钥基础设施。到目前为止，我一直避免过多地使用这个术语，除非你深入了解一些细节，否则它看起来非常抽象。

文章参考自:

FreeBuf.COM

自制Https证书并在Spring Boot和Nginx中使用

---