Warum gibt OpenVPN den Fehler "Nicht unterstützter Zertifikatzweck" für ein Zwischenzertifikat aus?

7

EDIT: Es tut mir wirklich leid zu sagen, dass sich das Problem auf magische Weise selbst behoben hat und ich keine Ahnung habe warum. Als Antwort auf eine der Antworten habe ich alle EKU aus der CA-Kette entfernt und es hat nicht funktioniert. Nachdem ich aus dem Urlaub zurückgekommen war, habe ich jeweils die Zertifikatskette 1 erstellt, d. H. RootCA->VPNdann RootCA->IntermediateCA->VPNund endlich RootCA->IntermediateCA->ServerCA->VPNund es hat immer noch funktioniert! Ich habe keine Ahnung, warum es funktioniert hat, aber ich war begeistert. Nur um absolut sicherzugehen, dass es die Entfernung der EKU war, die es gelöst hat, ging ich zurück und fügte zufällige EKU zu CAs in der Kette hinzu, und siehe da, es funktioniert immer noch ... Das ist absolut ärgerlich und ich entschuldige mich bei all die Leute, die versucht haben zu helfen. Ich schwöre, absolut nichts anderes hat sich geändert und niemand hat in meiner Abwesenheit etwas berührt. END EDIT

Beim Versuch, einen OpenVPN-Client (Android oder Windows 7/10) mit meinem Testserver zu verbinden, wird folgende Fehlermeldung angezeigt:

FEHLER PRÜFEN: Tiefe = 1, Fehler = nicht unterstützter Zertifikatszweck: C = CA, ST = QC, L = Montreal, O = Company Inc, OU = PKI, CN = Server Certificate Authority

Ich verwende OpenVPN 2.3.7 unter OpenBSD. Ich verwende die folgende mit XCA erstellte PKI-CA-Hierarchie :

RootCA -> IntermediateCA -> ServerCA

Ich habe ein Zertifikat für meinen VPN-Server erstellt, das von meinem ServerCA signiert ist. Bitte beachten Sie die Tiefe = 1 . Dies scheint kein Problem mit dem endgültigen VPN Server-Zertifikat zu sein. OpenVPN beschwert sich über den Aussteller des VPN-Serverzertifikats. Sogar der CN in der Fehlermeldung ist der von ServerCA, NICHT vom VPN-Server.

Soweit ich feststellen konnte, muss eine Zertifizierungsstelle in der Kette keinen anderen Zweck haben als das Signieren von Zertifikaten.

Hier ist die Konfiguration des Zertifikats des VPN-Servers. Beachten Sie, dass die alte Netscape-Servererweiterung vorhanden ist, wie von OpenVPN gefordert:

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

Hier ist die Konfiguration des Zertifikats der ausstellenden Zertifizierungsstelle:

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

Ich habe versucht nsCertType=server, ServerCA hinzuzufügen , aber es gab keine Änderung.

Ich habe auch endlose Forenbeiträge gesehen, in denen Leute vergessen haben, die Erweiterung nsCertType hinzuzufügen, und einen Fehler erhalten haben, der meinem ähnlich ist, aber depth=0stattdessen mit. In meinem Fall scheint das Zertifikat des Servers in Ordnung zu sein.

Kann mir jemand sagen, warum OpenVPN sich darum kümmert, was eine Zertifizierungsstelle in der Kette tun darf (außer natürlich das Signieren von Zertifikaten)? Wie kann ich sehen, welchen "Zertifikatzweck" der Client erwartet hat? Wie kann ich OpenVPN dazu bringen, die Zertifikatkette zu akzeptieren?

Wie angefordert, ist hier das Zertifikat des VPN-Servers:

$ 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
        **:**:**:**:**:**:**:**

Und hier ist das Zertifikat des Ausstellers:

$ 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
         **:**:**:**:**:**:**:**
ssl-certificate openvpn pki succulent_headcrab
quelle
Ich habe mich entschieden, hier statt in Sicherheit zu posten, da es bei meiner Frage mehr darum geht, wie meine Konfiguration funktioniert, als um mögliche Sicherheitsprobleme.
succulent_headcrab
Veröffentlichen Sie den Text der Zertifikate - sie geben möglicherweise mehr Aufschluss über das Problem. Verwenden Sie openssl x509 -noout -text -in <certfile>für jeden.
GarethTheRed
@garethTheRed Ich habe die Zertifikate vom VPN-Server und der ausstellenden Zwischenzertifizierungsstelle hinzugefügt.
succulent_headcrab

Antworten:

4

Es ist die EKU (ExtendedKeyUsage-Erweiterung)

rfc 5280 4.2.1.12 extKeyUsage sagt

Im Allgemeinen wird diese Erweiterung nur in Endentitätszertifikaten angezeigt.

CABforum Baseline Requirements (v1.3.4) 7.2.2 g bestätigt dies, erlaubt aber zusammen mit 7.1.5 einen Fall:

Damit ein untergeordnetes CA-Zertifikat als technisch eingeschränkt betrachtet werden kann, MUSS das Zertifikat eine EKU-Erweiterung (Extended Key Usage) enthalten, in der alle erweiterten Schlüsselverwendungen angegeben sind, für die das untergeordnete CA-Zertifikat Zertifikate ausstellen darf. Die anyExtendedKeyUsage KeyPurposeId darf in dieser Erweiterung NICHT angezeigt werden.

Die EKU ist somit keine Einschränkung für die Verwendung eines eigenen Schlüssels durch die Zertifizierungsstelle, sondern für die Verwendung von Schlüsseln mit Zertifikaten gemäß der Zertifizierungsstelle durch die EE. Dies ist ähnlich wie die Art und Weise Policies (meistens) und NameConstraints propagieren nach unten, und im Gegensatz zu KeyUsage , die sich an die CA selbst anwenden.

Und genau das implementiert OpenSSL und damit OpenVPN mit OpenSSL. Wenn auf jedem CA-Zertifikat in einer Serverkette eine EKU vorhanden ist, muss diese serverAuth oder SGC enthalten . Ebenso muss jedes CA-Zertifikat in einer Clientkette mit EKU clientAuth enthalten.

Ihre Zwischenzertifizierungsstelle über Ihrem Server verfügt über eine EKU mit OCSPSign, jedoch nicht über serverAuth. Daher wird sie abgelehnt.

Referenz: crypto/x509/x509_vfy.cund crypto/x509v3/v3_purp.cin openssl-1.0.2h

dave_thompson_085
quelle
Aber in meinem Fall hat die Zwischenzertifizierungsstelle nur keyUsage = keyCertSign, cRLSign und es funktioniert
Dilyin
@dilyin Ihre veröffentlichten Daten sind inkonsistent und scheinen dieses Zwischenprodukt nicht anzuzeigen . Aber selbst wenn ein Zwischenprodukt diese KeyUsage hat (die entweder für die Stamm- oder die Zwischenzertifizierungsstelle korrekt sein kann), betrifft das in meiner Antwort beschriebene Problem ExtendedKeyUsage, nicht KeyUsage .
Dave_thompson_085
Ja, vielleicht hast du recht. Sie sagten, "wenn EKU vorhanden ist", aber in meinem Fall ist EKU in CA-Zertifikaten nicht nur auf dem Client und dem Server vorhanden.
Dilyin
@ dave_thompson_085 Vor 2 Wochen habe ich keine EKU irgendwo in der Zertifizierungskette ausprobiert und den gleichen Fehler erhalten. Heute habe ich meine Zertifikate einzeln erstellt, dh das RootCA hat das VPN signiert, dann das Zwischenprodukt und schließlich das ServerCA hinzugefügt. Es hat bei jedem Schritt funktioniert! Ich war im Urlaub und es wurden nirgendwo Änderungen vorgenommen.
succulent_headcrab
@ dave_thompson_085 Ich wollte Ihre Antwort akzeptieren, vorausgesetzt, ich habe beim letzten Mal etwas verpasst, aber dann habe ich der CA-Kette eine zufällige EKU hinzugefügt, und siehe da, es hat immer noch funktioniert! Ich bin völlig ratlos, aber es scheint, dass die EKU mein Problem nicht verursacht hat und tatsächlich so zu funktionieren scheint, wie es der RFC5280 beschrieben hat, und nicht das CABforum (Es schien mir, dass diese Seite eher auf "echte" Werbung ausgerichtet war CAs im Internet)
succulent_headcrab
4

Hmm, die Easyrsa von OpenVPN erstellt folgende Zertifikate:

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

Server:

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

Klient:

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

Aber Sie haben auch diese Key Usage-Werte, also sollte Ihre Konfiguration funktionieren ... Aber es gibt keine Zwischenzertifizierungsstelle ...

Haben Sie versucht, --ca auf das Zertifikat der Stammzertifizierungsstelle und --extra-certs auf die Zwischenzertifizierungsstelle und --cert auf das Serverzertifikat zu setzen, um eine vollständige Kette zu bilden? Und vergiss nicht - Schlüssel auch.

Eigentlich habe ich es zum Laufen gebracht:

Server:

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

Klient:

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

Server conf:

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 conf:

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

XCA

Dilyin
quelle
Dies ist so ziemlich auch mein Setup. Ich habe sichergestellt, dass ich meine Zertifikatskette mit überprüfen kann, openssl verifysodass ich den Parameter "extra-certs" nie verwendet habe. Ich habe es mit dem Zwischenzertifikat versucht, aber es machte keinen Unterschied. Ich habe immer noch die gleiche Fehlermeldung erhalten.
succulent_headcrab
Könnten Sie versuchen, mit easyrsa erneut Zertifikate zu generieren? Vielleicht haben Sie versehentlich etwas durcheinander gebracht.
Dilyin
1

Ich hatte ein ähnliches Problem mit stunnel und openssl unter Linux

Ich habe festgestellt, dass die Serverseite erwartet, dass alle Client- und CA-Zertifikate Folgendes enthalten: Erweiterte Schlüsselverwendung: TLS-Webclient-Authentifizierung

Es wurde festgestellt, dass die Clientseite erwartete, dass alle Server- und CA-Zertifikate Folgendes enthalten: X509v3 Erweiterte Schlüsselverwendung: TLS-Webserverauthentifizierung

Da ich dieselben Zertifizierungsstellen zum Signieren der Client- und Serverzertifikate verwendet habe, habe ich die CA-, CA1- und CA2-Zertifikate so getestet, dass sie sowohl clientAuth als auch serverAuth enthalten, und das Problem wurde behoben.

CA, CA1 und CA2: Erweiterte X509v3-Schlüsselverwendung: TLS-Webclientauthentifizierung, TLS-Webserverauthentifizierung

Client-Zertifikat: X509v3 Erweiterte Schlüsselverwendung: TLS-Webclient-Authentifizierung

Serverzertifikat: X509v3 Erweiterte Schlüsselverwendung: TLS-Webserverauthentifizierung

kevinM
quelle