如何使用 openssl 获取根 CA 证书指纹

Question

通过使用以下命令，我可以验证所提供证书的 sha1 指纹：

$ openssl s_client -connect hooks.slack.com:443 -showcerts < /dev/null 2>/dev/null   | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint
SHA1 Fingerprint=AB:F0:5B:A9:1A:E0:AE:5F:CE:32:2E:7C:66:67:49:EC:DD:6D:6A:38

但是如果我想获得顶级签名机构的指纹呢？

$ openssl s_client -connect hooks.slack.com:443 < /dev/null 2>/dev/null
CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Slack Technologies, Inc/CN=*.slack.com
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA <- **I WANT THIS SHA1**

如果我想根据 Java 密钥库对此进行验证，以明确检查它是否包含相同的 CA。

geotrustglobalca, 18-Jul-2003, trustedCertEntry,
Certificate fingerprint (SHA1): DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12

因为“geotrustglobalca”和“/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA”没有可比性。

Answer 1

在类似的情况下，在共享主机解决方案上使用 let's encrypt 证书，我成功地指定了 servername 参数：

openssl s_client -connect hooks.slack.com:443 -servername hooks.slack.com -showcerts < /dev/null 2>/dev/null   | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint

Answer 2

我不确定这是否直接回答了您的问题，但如果服务器将根证书作为链的一部分提供（这是可选的，因此可能不是），您可以使用 -showcerts 选项来显示所有证书.

我之前把它放在一起（希望有人可以改进）以获得每个证书的指纹。如果需要，您可以在最后使用 openssl x509 的参数来获取不同的信息。

echo "" | openssl s_client -showcerts -connect eistest.mtsu.edu:443 2>&1 |\ 
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p;/-END CERTIFICATE-/a\\x0' |\ 
sed -e '$ d' |\ 
xargs -0rl -I% sh -c "echo '%' | openssl x509 -subject -issuer -fingerprint -noout"

向 openssl s_client 回显一个空字符串可以防止它等待连接超时。 第一个 sed 将仅输出 PEM 格式的证书，以 NUL 字符分隔。

Answer 3

因为“geotrustglobalca”和“/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA”没有可比性。

我将带着“X.509 证书等效性”的答案进入池中，因为它并不明显或不容易获得。

首先，您应该小心比较证书是否相等。如果<certificate bits 1> == <certificate bits 2>，那么您可以说它们是完全相同的证书并且相等。但是，反过来不成立。

要理解反过来，你需要知道两件事。首先，CA 有时会重新颁发具有几乎相同参数的证书。基于主题名称，它们是等价的；但基于它们不相等的位。一些 CA 过去曾这样做以从 SHA-1 升级到 SHA-256。

要了解的第二件事是，重要的位是什么，以便您可以确定证书是否等效。 IETF 没有 X.509 验证文档。最接近的是RFC 4158: Internet X.509 Public Key Infrastructure: Certification Path Building，与其他一些文档混合在一起，例如发布规则（与验证规则不同）。

根据 RFC 4158，您可以使用以下任一方式唯一标识证书：

• {Issuer DN, Serial Number}对
• {Authority Key identifier (AKID), Subject Key identifier (SKID)}对

CA 重新颁发根 CA 的极端情况会导致：

1. 哈希变化
2. 序列号更改
3. 公钥仍然存在
4. 专有名称仍然存在

第 (3) 项，公钥仍然存在，很重要，因为它既不表示 授权密钥标识符 (AKID)，也不表示 主题密钥标识符 (SKID) ) 变化。第 (4) 项，专有名称仍然存在，很重要，因为它是许多人用来比较的（多年来它是许多安全漏洞的原因）。

在这种情况下，密钥标识符将是相同的，因此即使序列号已更改，您也应该考虑接受。 （序列号必须根据 IETF 和 CA/B 规则更改）。

最近在公钥固定中出现的一个非常奇怪的极端情况是，服务器使用域参数（p、g、Q 等的完整扩展）提供椭圆曲线证书，但是客户端需要一个命名曲线（如secp256r1）。是否应该将此密钥视为等效项？ （IETF 规定证书必须使用命名曲线）。

---

鉴于以上信息，这些信息在您的比较中是无用的：

• "geotrustglobalca"

而且此信息不完整，无法供您比较：

• "/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA"

在这种情况下，您应该谨慎行事并拒绝进行相等或等价的比较。