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

让我们花几分钟时间讨论一下中间证书和根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中使用

8月6号，Let’s Encrypt 官方博客发表了一篇文章 Let's Encrypt Root Trusted By All Major Root Programs ，其中关键信息引用如下：

意思就是本月底，所有的微软产线（比如 Edge）也将直接信任 Let’s Encrypt 的根证书（ISRG Root X1），从而世界上所有的主流产品都直接支持其根证书了，那么这意味着什么？什么是直接信任？对使用 Let’s Encrypt 的证书的人有何影响？且听我慢慢道来。

这一消息表示：

也许你听的晕晕乎乎的，为了解明白，我们必须理解证书链的概念。

证书链是一个信任链，关系见下图：

以 Let’s Encrypt 签发的证书为例，申请者申请的证书可以称为服务器证书，运行 openssl 查看证书命令，关键信息如下：

这表示服务器证书是 *.simplehttps.com，它被中间证书 Let's Encrypt Authority X3 进行数字签名，也就是说服务器证书被 Authority X3 中间证书信任。

该中间证书就是 Let's Encrypt CA 机构的，用于签发服务器证书，需要说明的是中间证书可能有多张，迭代签名。

那么中间证书被谁签名了？运行下列命令：

中间证书是被 DST Root CA X3 根证书（IdenTrust CA 机构的根证书）签名的，同学们可能很奇怪了，为啥 Let's Encrypt 不用自己的根证书签名其中间证书啊？这是一个好问题。

根本原因就是 Let's Encrypt 作为一个新兴 CA 机构，历史并不悠久，大部分浏览器不可能直接信任其根证书，不信任就无法构建信任基础，怎么办？Let's Encrypt 为了快速投入运营，使用 IdenTrust CA 机构的根证书（被主流产品直接信任，比如 Chrome 可信任根证书列表包含该根证书）对其中间证书进行 交叉认证 ，从而主流产品就能信任 Let's Encrypt 服务器证书了，最终信任链链条： 服务器证书>Let's Encrypt Authority X3 中间证书->DST Root CA X3 根证书 。

同学们如果也使用 Let's Encrypt 证书，可以看一下证书链，打开 Chrome 开发者工具就能知晓，如图：

本质上，Let's Encrypt 有两条证书链（早就存在了）如下图：

绿色线条就是目前采用的证书链，如果主流浏览器都信任了 Let's Encrypt 根证书（ISRG Root X1），那么就可以采用红色线条标示的证书链了。也就是信任链链条： 服务器证书>Let's Encrypt Authority X3 中间证书->ISRG Root X1 根证书 。

经过我的配置，我的网站证书链如下图：

同学们可能会问，这是如何做到的？别着急。

本质上，Let's Encrypt 中间证书 Authority X3 有两个证书，分别是：

他们都可以对 Let's Encrypt 服务器证书进行签名（签名用的私钥是一样的），这是关键，这两个证书分别被 ISRG Root X1 和 DST Root CA X3 签名。

聪明的同学可能想到了，在申请 Let's Encrypt 证书的时候，Let's Encrypt 目前使用 Let’s Encrypt Authority X3 (IdenTrust cross-signed) 签名，申请者获取到证书后，配置证书链（服务器证书+中间证书）后提供 HTTPS 服务。浏览器校验证书，一看中间证书是 Let’s Encrypt Authority X3 (IdenTrust cross-signed) 签名，最终找到 IdenTrust 的根证书完成签名验证。

那今天博客所说的内容表示，在申请 Let's Encrypt 证书的时候，Let's Encrypt 可以使用 Let’s Encrypt Authority X3 (Signed by ISRG Root X1) 签名，申请者获取到证书后，配置证书链（服务器证书+中间证书）后提供 HTTPS 服务。浏览器校验证书，一看中间证书是 Let’s Encrypt Authority X3 (Signed by ISRG Root X1) 签名，最终找到 Let's Encrypt ISRG Root X1 根证书完成签名验证。

可实际上， 目前 你申请证书的时候，Let's Encrypt 仍然使用 IdenTrust cross-signed 中间证书签名服务器证书，原因何在，主流产品（比如 Chrome）虽然已经直接信任其根证书了，但这些产品有很多旧版本存在，如果不更新，那么这些版本仍然不信任 Let’s Encrypt 根证书，Let’s Encrypt 预估 5 年以后，这些旧版本将不复存在，那个时候 Let’s Encrypt 就可以大胆用 Let’s Encrypt Authority X3 (Signed by ISRG Root X1) 中间证书签发服务器证书了。

难倒我们了吗？是否可以手动让你的网站使用新的证书链呢？答案是可以（如果不考虑旧产品线不信任 Let’s Encrypt ISRG Root X1 根证书的问题）。

上面讲到，服务器证书可以任意使用下面的中间证书签名：

任意的关键就是，这两个证书的签名私钥是一样的，我们是否可以自行配置证书链呢（红色线条）？可以：

然后重新启动你的服务器，使用 Chrome 浏览器开发者工具观察网站证书链，是不是结果如下图：

---