时间戳

首页 > 解决方案 > openssl 为过期的证书返回“验证返回码：0（ok）”

openssl - openssl 为过期的证书返回“验证返回码：0（ok）”

问题描述

我openssl用来查看似乎已过期的证书：

# Write the certificate chain to a file
</dev/null openssl s_client -showcerts -connect testauth.assurity.com:443 > cert-chain.pem
# Separate chain into individual certificate files
csplit -z -f chain-link- cert-chain.pem '/--BEGIN CERT/' '{*}'
# Output the hash and dates for each certificate
for f in chain-link-01 chain-link-02 chain-link-03; do
  openssl x509 -noout -enddate -hash -subject -in $f
done

chain-link-03 的 openssl 输出包括行notAfter=May 30 10:48:38 2020 GMT; 这是一个过期的证书。openssl s_client -showcerts -connect testauth.assurity.com:443然而，当我从两台不同的机器上运行时，我得到了两种不同的结果：

  1. 从我的工作站，openssl 输出Verify return code: 0 (ok)
  2. 从我的服务器，openssl 输出Verify return code: 10 (certificate has expired)

这里发生了什么？在我的工作站和服务器上运行上面的脚本会为每个证书输出一个哈希和主题，这表明两台机器正在从testauth.assurity.com:443. 我想知道为什么两台机器中只有一台返回非零，以及我是否需要联系 Assurity 让他们更新他们的证书。

底线：我正在运行一个 ruby​​-on-rails 应用程序，该应用程序testauth.assurity.com从我的工作站发出成功的请求，而不是从我的服务器发出请求。在服务器上，ruby-on-rails 应用程序拒绝发出请求，说明：

SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate has expired).

标签： opensslssl-certificate

解决方案

TLDR：这可能是一条替代路径

今天大多数公开发行的证书都使用一个中间 CA，因此 01 将是您的叶证书，02 是中间 CA，而 03 可以是根证书（这是多余的）或该根的“桥”又名“交叉”证书不同的根。这通常在创建新 CA 时完成，并且最初不在现有系统、平台和库的信任库中；它由不同的、现有的且已受信任的 CA“交叉签名”。但是，即使新 CA 随后确实拥有其（自己的）根证书受信任，服务器通常仍会继续为（过时的）桥接证书提供服务，因为它没有损坏。

举个方便的例子，这种情况在 Google上已经发生过两次。谷歌过去常常在 GeoTrust 下为其网站获取证书，这在本世纪初由 Equifax 桥接；参见例如
https://security.stackexchange.com/questions/93081/gmail-x-509-certificate-chain
https://security.stackexchange.com/questions/171983/server-certificate-terminates-in-removed- ca-certificate-still-works
https://serverfault.com/questions/841036/openssl-unable-to-get-local-issuer-certificate-for-accounts-google-com
在 GeoTrust 在赛门铁克错发问题中受到污染之后（绕口令！），谷歌转入 GlobalSign 旗下，但也开始在信任计划中扎根，今天https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com&s=216.58.195.68&hideResults=on&ignoreMismatch=on显示使用了两个叶证书（一个 RSA，一个 EC），这两个叶证书GTS CA 1C3依次使用可以通过网桥验证，GlobalSign Root CA也可以直接通过GTS Root R1（SSLLabs 将其显示为“信任存储”和“额外下载”！）“GTS”表示 Google 信任服务，即他们的 CA。

如果 02 是到旧根 03 的桥，并且与 02 相同的 CA（如果存在，则相同的主题和 SKI）的新根可用，则可能会发生类似的情况，但这意味着叶证书是由根直接颁发的，违反了 CABforum 规则；这可能是不遵循公共规则的内部或私有 CA，但我希望它在您使用的所有系统中手动维护并且不会变化。

因此，我追溯您的工作站在其信任库中有一个（可能是较新的）直接根目录，用于与您的 03 证书中相同的 CA，但您的服务器没有，因此继续使用过期和无效的网桥。也可以想象，服务器有根，但使用的是旧的（1.0.2 之前）版本的 OpenSSL，它没有实现备用链逻辑，但在 2021 年这种可能性不大。

我无法验证自己，因为我的系统和 SSLLabs 都无法连接testauth.assurity.com（解析为 216.229.15.88）。

推荐阅读