我有一个简单的链设置，在这种情况下可以成功验证:

$ openssl version
OpenSSL 1.0.2m  2 Nov 2017
$ openssl verify -CAfile chain.pem cert.pem
cert.pem: OK

但是在这些情况下我会收到错误:

$ openssl verify -CAfile ca-cert.pem cert.pem
cert.pem: C = US...
error 2 at 1 depth lookup:unable to get issuer certificate

特别是无法获得颁发者证书。

也可以在这里获取:

$ openssl verify chain.pem
chain.pem: C = US...
error 20 at 0 depth lookup:unable to get local issuer certificate

$ openssl verify cert.pem
cert.pem: C...
error 20 at 0 depth lookup:unable to get local issuer certificate

最后，当我将 key 传递给 HTTPS 服务器时，我在 Node.js 中得到它:

events.js:193
      throw er; // Unhandled 'error' event
      ^

Error: unable to get local issuer certificate
    at TLSSocket.onConnectSecure (_tls_wrap.js:1036:34)
    at emitNone (events.js:115:13)
    at TLSSocket.emit (events.js:218:7)
    at TLSSocket._finishInit (_tls_wrap.js:637:8)

我尝试使用 { key, cert, ca } 传递它，但仍然是同样的错误。

想知道如何进行调试或解决什么问题才能让 HTTPS 服务器运行。

如果我使用 pfx 文件，我会得到以下信息:

events.js:193
      throw er; // Unhandled 'error' event
      ^

Error: self signed certificate in certificate chain
    at TLSSocket.onConnectSecure (_tls_wrap.js:1036:34)
    at emitNone (events.js:115:13)
    at TLSSocket.emit (events.js:218:7)
    at TLSSocket._finishInit (_tls_wrap.js:637:8)

如果我只在 cert 文件中保留 cert.pem，并将 ca 属性设为 ca-cert.pem，它会给出:

Error: unable to verify the first certificate
    at TLSSocket.<anonymous> (_tls_wrap.js:1108:38)
    at emitNone (events.js:105:13)
    at TLSSocket.emit (events.js:207:7)
    at TLSSocket._finishInit (_tls_wrap.js:638:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:468:38)

不知道该怎么办。

Here他们说:

OpenSSL is unable to find a local certificate for the issuer (or the issuer of the first certificate in the chain received from the web server during the TLS handshake) with which to verify the signature(s).

不知道这是什么意思。

This error means the certificate path or chain is broken and you are missing certificate files.

- https://wiki.zimbra.com/wiki/Fix_depth_lookup:unable_to_get_issuer_certificate

更新

更多帮助:

This problem is usually indicated by log messages saying something like "unable to get local issuer certificate" or "self signed certificate". When a certificate is verified its root CA must be "trusted" by OpenSSL this typically means that the CA certificate must be placed in a directory or file and the relevant program configured to read it. The OpenSSL program 'verify' behaves in a similar way and issues similar error messages: check the verify(1) program manual page for more information.

• https://www.openssl.org/docs/faq.html#USER6

但仍然没有太大帮助。

看起来 Node.js 使用的是 1.0.2l 而不是 1.0.2m，但似乎没什么大不了的。

$ node -pe process.versions | grep openssl
  openssl: '1.0.2l'

更新 2

奇怪，当我从 Node.js 发出请求时，我得到了这个:

Uncaught Error: unable to verify the first certificate
      at TLSSocket.onConnectSecure (_tls_wrap.js:1036:34)
      at TLSSocket._finishInit (_tls_wrap.js:637:8)

但是当我去浏览器时，我没有看到“谨慎操作”页面，并且可以在Node.js中成功记录一个请求。也许这有点帮助。请帮忙:D

最佳答案

(此答案从 crypto/x509/x509_vfy.c:204 的 X509_verify_cert 中提取，在 openssl-1.0.2m 中)

OpenSSL verify 应用程序通过以下方式验证证书:它从目标证书开始构建证书链，并跟踪颁发者链，首先搜索与目标证书一起提供的任何不受信任的证书.在未能找到不受信任的颁发者证书时，OpenSSL 切换到受信任的证书存储并继续构建链。当

1. 在受信任的商店中找不到发行者。
2. 遇到自签名证书。
3. 遇到最大验证深度。

此时，我们的链可能会提前结束(如果我们未能找到发行者，或者如果我们超出了验证深度)。

OpenSSL 然后扫描链上的每个受信任证书，寻找指定受信任证书用途的 SSLv3 扩展。如果受信任的证书具有用于验证操作“目的”的正确“信任”属性(或具有 anyExtendedKeyUsage 属性)，则该链是受信任的。 (原谅关于信任属性的手波，那部分代码很难阅读。)

所以让我们测试一下。首先，让我们重现 OP 的错误案例:

#
echo "Making Root CA..."
openssl req -newkey rsa:4096 -nodes -keyout ca-key.pem -sha384 -x509 -days 365 -out ca-crt.pem -subj /C=XX/ST=YY/O=RootCA

echo "Making Intermediate CA..."
openssl req -newkey rsa:3072 -nodes -keyout int-key.pem -new -sha384 -out int-csr.pem -subj /C=XX/ST=YY/O=IntermediateCA
openssl x509 -req -days 360 -in int-csr.pem -CA ca-crt.pem -CAkey ca-key.pem -CAcreateserial -out int-crt.pem

echo "Making User Cert..."
openssl req -newkey rsa:2048 -nodes -keyout usr-key.pem -new -sha256 -out usr-csr.pem -subj /C=XX/ST=YY/O=LockCmpXchg8b
openssl x509 -req -days 360 -in usr-csr.pem -CA int-crt.pem -CAkey int-key.pem -CAcreateserial -out usr-crt.pem

echo ""
echo "Making Chain..."
cat ca-crt.pem int-crt.pem > chain.pem

echo ""
echo "Verfying UserCert via RootCA..."
openssl verify -CAfile ca-crt.pem usr-crt.pem

echo ""
echo "Verfying UserCert via IntermediateCA..."
openssl verify -CAfile int-crt.pem usr-crt.pem

echo ""
echo "Verfying UserCert via chain..."
openssl verify -CAfile chain.pem usr-crt.pem

产量

[... Skipping OpenSSL KeyGen / CertGen verbosity ...]
Making Chain...

Verfying UserCert via RootCA...
usr-crt.pem: C = XX, ST = YY, O = LockCmpXchg8b
error 20 at 0 depth lookup:unable to get local issuer certificate

Verfying UserCert via IntermediateCA...
usr-crt.pem: C = XX, ST = YY, O = IntermediateCA
error 2 at 1 depth lookup:unable to get issuer certificate

Verfying UserCert via chain...
usr-crt.pem: OK

现在，让我们使用 openssl x509 的 -addtrust 选项来确保我们在中间 CA 上具有可接受的信任属性之一(称之为 IntermediateCAWithTrust；我们将使用它来签署 AnotherUserCert。):

echo ""
echo "Alternate Intermedate CA (using -addtrust anyExtendedKeyUsage)"
echo ""

echo "Making IntermediateCAWithTrust..."
openssl req -newkey rsa:3072 -nodes -keyout int-key2.pem -new -sha384 -out int-csr2.pem -subj /C=XX/ST=YY/O=IntermediateCAWithTrust
openssl x509 -req -days 360 -in int-csr2.pem -CA ca-crt.pem -CAkey ca-key.pem -CAcreateserial -out int-crt2.pem -addtrust anyExtendedKeyUsage

echo "Making AnotherUser Cert..."
openssl req -newkey rsa:2048 -nodes -keyout usr-key2.pem -new -sha256 -out usr-csr2.pem -subj /C=XX/ST=YY/O=LockCmpXchg8b_2
openssl x509 -req -days 360 -in usr-csr2.pem -CA int-crt2.pem -CAkey int-key2.pem -CAcreateserial -out usr-crt2.pem

echo ""
echo "Verfying AnotherUserCert via IntermediateCAWithTrust..."
openssl verify -CAfile int-crt2.pem usr-crt2.pem

这会产生

Alternate Intermedate CA (using -addtrust anyExtendedKeyUsage)

Making IntermediateCAWithTrust...
[... Snip more OpenSSL generation output ...]
Making AnotherUser Cert...
[... Snip more OpenSSL generation output ...]

Verfying AnotherUserCert via IntermediateCAWithTrust...
usr-crt2.pem: OK

嘿看!我们刚刚通过 IntermediateCAWithTrust 成功验证了 AnotherUserCert，即使我们没有提供整个链。这种差异的关键在于链中的任何一个受信任证书都具有用于验证操作的适当信任属性。

仔细看(通过 openssl x509 -in ca-crt.pem -noout -text)，我们的 CA 证书有

        X509v3 Basic Constraints:
            CA:TRUE

我认为 OpenSSL 将其视为一般的“可以出于任何目的验证”扩展。新的 IntermediateCAWithTrust 没有 X509v3 Basic Constraints，而是有

Trusted Uses:
  Any Extended Key Usage
No Rejected Uses.

有关-addtrust 选项的更多信息，以及可以添加的信任属性类型，请参阅https://www.openssl.org/docs/manmaster/man1/x509.html#TRUST_SETTINGS

该页面底部附近是前面讨论的简明摘要:

The basicConstraints extension CA flag is used to determine whether the certificate can be used as a CA. If the CA flag is true then it is a CA, if the CA flag is false then it is not a CA. All CAs should have the CA flag set to true.

If the basicConstraints extension is absent then the certificate is considered to be a "possible CA" other extensions are checked according to the intended use of the certificate. A warning is given in this case because the certificate should really not be regarded as a CA: however it is allowed to be a CA to work around some broken software.

因此，简而言之，请确保您的中间 CA 是正确的 CA(在它们的 X509v3 基本约束 中)。这似乎是一个极好的教程(它显式地将中间 CA 生成为 CA):https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

作为备用计划，您可以始终提供整个链，或者您可以使用 -addtrust hack 制作中间 CA。

关于node.js - OpenSSL 错误 - 无法获取本地颁发者证书，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47585757/