☰

为什么 OpenVPN 会针对中间证书给出错误：“不支持的证书用途”？

tag-icon • tag-icon ssl-certificate openvpn pki
为什么 OpenVPN 会针对中间证书给出错误：“不支持的证书用途”？

编辑：我真的很抱歉，不得不说问题已经神奇地自行解决了，我不知道为什么。在回答其中一个答案时，我从 CA 链中删除了所有 EKU，但它不起作用。休假回来后，我一次创建 1 个证书链，即RootCA->VPN然后RootCA->IntermediateCA->VPN，最后，RootCA->IntermediateCA->ServerCA->VPN它仍然有效！我不知道它为什么会起作用，但我很激动。为了确保是删除 EKU 解决了问题，我回去向链中的 CA 添加了随机 EKU，瞧，它仍然有效......这绝对令人愤怒，我向所有试图提供帮助的人道歉。我发誓，绝对没有其他变化，在我不在的时候没有人动过任何东西。结束编辑

当尝试将 OpenVPN 客户端（Android 或 Windows 7/10）连接到我的测试服务器时，我收到以下错误：

验证错误：深度=1，错误=不支持的证书目的：C=CA、ST=QC、L=Montreal、O=Company Inc、OU=PKI、CN=服务器证书颁发机构

我在 OpenBSD 上运行 OpenVPN 2.3.7。我使用以下 PKI CA 层次结构，该层次结构使用西卡：

RootCA -> IntermediateCA -> ServerCA

我为我的 VPN 服务器创建了一个由我的 ServerCA 签名的证书。请注意深度=1。这似乎不是最终 VPN 服务器证书的问题。OpenVPN 抱怨發行人VPN 服务器证书。错误消息中的 CN 也是 ServerCA 的，而不是 VPN 服务器的。

据我所知，除了签署证书之外，不需要链中的 CA 有任何其他用途。

这是 VPN 服务器的证书配置。请注意，根据 OpenVPN 的要求，旧的 Netscape 服务器扩展已存在：

nsCertType=server, email
extendedKeyUsage=serverAuth, nsSGC, ipsecEndSystem, iKEIntermediate
keyUsage=digitalSignature, keyEncipherment, dataEncipherment, keyAgreement
authorityKeyIdentifier=keyid, issuer
subjectKeyIdentifier=hash
basicConstraints=CA:FALSE

以下是颁发 CA 证书的配置：

crlDistributionPoints=crlDistributionPoint0_sect
extendedKeyUsage=critical,OCSPSigning
keyUsage=critical,keyCertSign, cRLSign
authorityKeyIdentifier=keyid, issuer
subjectKeyIdentifier=hash
basicConstraints=critical,CA:TRUE,pathlen:0

[crlDistributionPoint0_sect]
fullname=URI:http://pki.company.ca/server.crl

我尝试添加nsCertType=server到 ServerCA，但没有任何变化。

我还看到无数论坛帖子，人们忘记添加 nsCertType 扩展，并收到与我类似的错误，但改为depth=0。就我而言，服务器的证书似乎没有问题。

有人能告诉我为什么 OpenVPN 关心证书链上 CA 被允许做什么（显然除了签署证书）？我如何才能看到客户端期望的“证书目的”是什么？我如何才能让 OpenVPN 接受证书链？

根据要求，这是 VPN 服务器的证书：

$ openssl x509 -noout -text -in vpn-server.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4 (0x4)
    Signature Algorithm: sha512WithRSAEncryption
        Issuer: C=CA, ST=QC, L=Montreal, O=Company Inc, OU=PKI, CN=Server Certificate Authority
        Validity
            Not Before: Jun 21 17:58:00 2016 GMT
            Not After : Jun 21 17:58:00 2021 GMT
        Subject: C=CA, ST=QC, L=Montreal, O=Company Inc, OU=VPN, CN=vpn.company.ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                **:**:**:**:**:**:**:**
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Subject Key Identifier:
                A9:EF:EB:8B:68:E2:5F:0A:5D:FC:8A:39:7D:59:BE:21:75:2A:CB:8E
            X509v3 Authority Key Identifier:
                keyid:60:F3:33:2C:F7:13:09:F8:5C:3C:B2:D1:0B:9D:7D:9E:86:6A:24:41
                DirName:/C=CA/ST=QC/L=Montreal/O=Company Inc/OU=PKI/CN=Intermediate Certificate Authority
                serial:03

            X509v3 Key Usage:
                Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, Netscape Server Gated Crypto, IPSec End System, 1.3.6.1.5.5.8.2.2
            Netscape Cert Type:
                SSL Server, S/MIME
    Signature Algorithm: sha512WithRSAEncryption
        **:**:**:**:**:**:**:**

这是颁发者的证书：

$ openssl x509 -noout -text -in server-ca.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3 (0x3)
    Signature Algorithm: sha512WithRSAEncryption
        Issuer: C=CA, ST=QC, L=Montreal, O=Company Inc, OU=PKI, CN= Intermediate Certificate Authority
        Validity
            Not Before: Jun 21 17:57:00 2016 GMT
            Not After : Jun 21 17:57:00 2026 GMT
        Subject: C=CA, ST=QC, L=Montreal, O=Company Inc, OU=PKI, CN= Server Certificate Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    **:**:**:**:**:**:**:**
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier:
                60:F3:33:2C:F7:13:09:F8:5C:3C:B2:D1:0B:9D:7D:9E:86:6A:24:41
            X509v3 Authority Key Identifier:
                keyid:09:26:2E:AB:F4:C1:53:E1:10:11:DE:25:2D:20:D5:76:27:A9:FF:23
                DirName:/C=CA/ST=QC/L=Montreal/O=Company Inc/OU=PKI/CN=Root Certificate Authority
                serial:02

            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: critical
                OCSP Signing
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://pki.company.ca/server.crl

    Signature Algorithm: sha512WithRSAEncryption
         **:**:**:**:**:**:**:**

答案1

这是 EKU（ExtendedKeyUsage 扩展）

rfc 5280 4.2.1.12 extKeyUsage 说

一般来说，此扩展只会出现在最终实体证书中。

CABforum 基线要求 （v1.3.4）7.2.2 g 确认了这一点，但与 7.1.5 一起允许一种情况：

要使下属 CA 证书被视为技术受限，该证书必须包含扩展密钥用法 (EKU) 扩展，指定下属 CA 证书有权颁发证书的所有扩展密钥用法。 anyExtendedKeyUsage KeyPurposeId 不得出现在此扩展中。

因此，EKU 并不限制 CA 使用自己的密钥，而是限制 EE 使用带有证书的密钥 在下面CA。这类似于策略（大部分）和 NameConstraints 向下传播的方式，与 KeyUsage 不同，后者做向 CA 本身提出申请。

这就是 OpenSSL 实现的，因此 OpenVPN 使用 OpenSSL 来实现。在每个 CA 证书上服务器链，如果存在 EKU，则必须包含 serverAuth 或 SGC. 类似地，具有 EKU 的客户端链中的每个 CA 证书都必须包含 clientAuth。

您服务器上方的中间 CA 具有带 OCSPSign 的 EKU，但没有 serverAuth，因此被拒绝。

参考：crypto/x509/x509_vfy.c以及crypto/x509v3/v3_purp.copenssl-1.0.2h 中

答案2

嗯，OpenVPN 的 easyrsa 创建的证书如下：

CA1：

X509v3 Subject Key Identifier:
87:13:73:D4:7C:9A:E1:EA:9A:F8:90:48:93:18:5A:B0:AF:B9:B6:25
X509v3 Authority Key Identifier:
keyid:87:13:73:D4:7C:9A:E1:EA:9A:F8:90:48:93:18:5A:B0:AF:B9:B6:25
DirName:/CN=Easy-RSA CA
serial:8B:E0:6F:16:C0:46:46:FC

X509v3 Basic Constraints:
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign

CA2：

X509v3 Basic Constraints:
CA:TRUE
X509v3 Subject Key Identifier:
D6:60:98:E7:6E:7C:73:9A:38:62:09:EC:C7:5D:62:15:89:AA:B2:8E
X509v3 Authority Key Identifier:
keyid:87:13:73:D4:7C:9A:E1:EA:9A:F8:90:48:93:18:5A:B0:AF:B9:B6:25
DirName:/CN=Easy-RSA CA
serial:8B:E0:6F:16:C0:46:46:FC

X509v3 Key Usage:
Certificate Sign, CRL Sign

服务器：

X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
53:BA:B4:3B:87:AC:89:41:14:28:8F:C9:A2:F3:38:D4:43:90:EF:A6
X509v3 Authority Key Identifier:
keyid:D6:60:98:E7:6E:7C:73:9A:38:62:09:EC:C7:5D:62:15:89:AA:B2:8E
DirName:/CN=Easy-RSA CA
serial:CB:8A:25:7F:5A:8A:A9:BD:63:D2:BE:B7:6C:5E:3E:75

X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication

客户：

X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
F5:34:3A:39:C6:90:E0:2F:E3:92:A7:D2:0D:18:C7:48:E6:48:9F:DA
X509v3 Authority Key Identifier:
keyid:D6:60:98:E7:6E:7C:73:9A:38:62:09:EC:C7:5D:62:15:89:AA:B2:8E
DirName:/CN=Easy-RSA CA
serial:CB:8A:25:7F:5A:8A:A9:BD:63:D2:BE:B7:6C:5E:3E:75

X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
TLS Web Client Authentication

但是您也有这些密钥用法值，所以您的配置应该可以工作...但是没有中间 CA...

您是否尝试设置--ca到根 CA 证书并设置--额外证书到中间 CA 和--证书到服务器证书以形成完整的链条？别忘了- 钥匙也。

实际上我已经让它工作了：

服务器：

Tue Jun 21 04:39:49 2016 VERIFY OK: depth=2, CN=Easy-RSA CA
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=1, O=Easy-RSA CA2, CN=Easy-RSA CA2
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=0, O=client, CN=client

客户：

Tue Jun 21 04:39:49 2016 VERIFY OK: depth=2, CN=Easy-RSA CA
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=1, O=Easy-RSA CA2, CN=Easy-RSA CA2
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=0, O=server, CN=server

服务器配置：

port 1194
proto tcp-server
dev tun
ca ca1.crt
extra-certs ca2.crt
cert server.crt
key server-key.pem
dh dh.pem
tls-server
tls-auth ta.key 0

客户端配置：

client
remote localhost 1194
port 1194
proto tcp-client
dev tun
ca ca1.crt
extra-certs ca2.crt
cert client.crt
key client-key.pem
dh dh.pem
tls-client
tls-auth ta.key 1

西卡

答案3

我在 Linux 上使用 stunnel 和 openssl 时也遇到了类似的问题

我发现服务器端要求所有客户端和 CA 证书都包含：扩展密钥用法：TLS Web 客户端身份验证

并且发现客户端期望所有服务器和 CA 证书都包含：X509v3 扩展密钥用法：TLS Web 服务器身份验证

由于我使用相同的 CA 来签署客户端和服务器证书，因此我通过设置 CA、CA1 和 CA2 证书以包含 clientAuth 和 serverAuth 进行了测试，并解决了该问题。

CA、CA1 和 CA2：X509v3 扩展密钥用法：TLS Web 客户端身份验证、TLS Web 服务器身份验证

客户端证书：X509v3 扩展密钥用法：TLS Web 客户端身份验证

服务器证书：X509v3 扩展密钥用法：TLS Web 服务器身份验证

答案4

  1. 就我的情况而言，当客户端和服务器上的时间相差太大时，我收到此错误消息。我通过在两台服务器上运行 ntpdate 来修复此问题：

    ntpdate 0.ubuntu.pool.ntp.org

    4月24日 09:40:32 ntpdate[6085]: 步骤时间服务器 178.79.145.244 偏移量 628.631158 秒

看来至少 628s = 10min 的时间漂移​​对于 openvpn（或 openssl）来说太多了。

  1. 然后我遇到了第二个问题，那就是我的 ca.crt 实际上 10 年后已经过期了：

    Validity
         Not Before: Apr 27 04:30:10 2011 GMT
         Not After : Apr 24 04:30:10 2021 GMT

解决方案：

重新生成 ca.crt 并重新颁发所有证书。

  1. 第三次，我仍然收到相同的错误，但这次是我有两个客户端证书尝试相互连接。接下来，我单独生成了一个服务器证书，请参阅http://gozer.ectoplasm.org/blog/archive/2007/07/openvpn_verify.html

相关内容