SSL证书链捆绑如何工作?

use*_*574 45 ssl openssl certificate ssl-certificate x509certificate

我已经创建了这样的链层次结构.

root-ca ==> signing-ca ==> subordinate-ca ==> server
Run Code Online (Sandbox Code Playgroud)

提到创建链束,最低应该先行.

$ cat server.crt subordinate-ca.crt signing-ca.crt > server.pem
Run Code Online (Sandbox Code Playgroud)

但验证失败了.

$ openssl verify -CAfile root-ca.crt server.pem
error 20 at 0 depth lookup:unable to get local issuer certificate
Run Code Online (Sandbox Code Playgroud)

但是,如果我改变顺序它似乎工作.

$ cat signing-ca.crt subordinate-ca.crt server.crt > server.pem
$ openssl verify -CAfile root-ca.crt server.pem
server.pem: OK
Run Code Online (Sandbox Code Playgroud)

那么这里的错误是什么?

"猫"之后的链条如下所示.

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Run Code Online (Sandbox Code Playgroud)

更多信息:根据" http://www.herongyang.com/crypto/openssl_verify_2.html ",我执行以下测试.

$ cat signing-ca.crt subordinate-ca.crt > inter.crt
$ openssl verify -CAfile root-ca.crt -untrusted inter.crt server.crt
server.crt: OK
Run Code Online (Sandbox Code Playgroud)

这是否意味着所有链接都很好?

好的,我终于发现这不能通过OpenSSL命令行完成(或者至少很容易).http://openssl.6102.n7.nabble.com/check-certificate-chain-in-a-pem-file-td43871.html

Vyn*_*nce 13

原始订单实际上是倒退的.证书应当遵循由发行证书,直到最后一个证书是由已知的每根发出IETF的RFC 5246第7.4.2节

这是证书的序列(链).发件人的证书必须在列表中排在第一位.以下每个证书必须直接证明其前面的证书.

另请参见SSL:错误:0B080074:x509证书例程:X509_check_private_key:用于故障排除技术的键值不匹配.

但我仍然不知道为什么他们编写规范以便订单很重要.

  • 对于与Nginx一起使用的证书包,需要颠倒捆绑中证书的顺序,首先是对等证书,然后是在根CA处结束的链.一致性肯定会很好!http://nginx.org/en/docs/http/configuring_https_servers.html (8认同)
  • **nginx 和标准相互匹配** RFC 说“发件人的证书必须在列表中排在第一位。” 和 nginx 说“服务器证书必须出现在组合文件中的链式证书之前:” (5认同)

Kla*_*ven 9

当前的最佳答案在多个层面上都是错误的。

首先,它忽略了主要问题,即“验证”并没有以这种方式验证单个文件中的证书链。证明:

$ cp /etc/ssl/certs/Certigna_Root_CA.pem /tmp/poc.pem
$ echo "unverifiable garbage" >> /tmp/poc.pem
$ openssl verify /tmp/poc.pem 
/tmp/poc.pem: OK
Run Code Online (Sandbox Code Playgroud)

因此,在原始问题中提供的 2 个顺序中,只有一开始就有根证书的顺序会报告“OK”,因为该调用仅单独检查根证书,并且该证书已被系统信任。

关于证书排序问题,标准中指定的顺序(“发送者的证书必须出现在列表中的第一位。”)和nginx的顺序(“服务器证书必须出现在组合文件中的链式证书之前”)匹配彼此。这对应于OP第一次尝试使用cat.

实际正确的答案位于OP 链接的电子邮件线程中。我在这里引用一下:

在命令行上,事情变得不必要地困难。

这是您需要做的:

  1. 将链文件拆分为每个证书一个文件,并注意顺序

  2. 对于以上面的根开头的每个证书:

2.1 将之前的所有证书和根证书连接到一个临时文件(此示例是在检查倒数第三个证书时,已经检查了 cert1.pem 和 cert2.pem)

Unix:    cat cert2.pem cert1.pem root.pem > cert2-chain.pem
Windows: copy /A cert1.pem+cert1.pem+root.pem cert2-chain.pem /A
Run Code Online (Sandbox Code Playgroud)

2.2 运行该命令

         openssl verify -CAfile cert2-chain.pem cert3.pem
Run Code Online (Sandbox Code Playgroud)

2.3 如果没问题,则继续进行下一个(本例中为 cert4.pem)

因此,对于第一轮,命令将是

Unix:cat root.pem > root-chain.pem Windows:copy /A root.pem root-chain.pem 两者:openssl verify -CAfile root-chain.pem cert1.pem

第二轮将是

Unix:cat cert1.pem root.pem > cert1-chain.pem Windows:copy /A cert1.pem+root.pem cert1-chain.pem 两者:openssl verify -CAfile cert1-chain.pem cert2.pem

ETC。

进一步说明:

  1. 步骤 1(分割文件)可以像这样自动化:
csplit -f cert- $file '/-----BEGIN CERTIFICATE-----/' '{*}'
Run Code Online (Sandbox Code Playgroud)
  1. openssl verify还从您的系统获取有关信任的信息(例如/etc/ssl/certs/),因此,如果您确实想确保正确验证,您的调用应该类似于openssl verify -verbose -x509_strict -CAfile upto-cert-02 -CAPath nosuchdir cert-01(其中 nosuchdir 是不存在的路径,并且upto-cert-02是文件 cert- 的串联) nn 到 certt02)