Nicht unterstützter Zertifikatszweck: Warum die Zwischen-CA scheitert

Der Zweck des Serverzertifikats sieht richtig aus, der Schlüssel passt, die Daten stimmen, und die Verbindung schlägt weiterhin mit unsupported certificate purpose fehl. Das entscheidende Detail steht meist in derselben Zeile wie der Fehler: ein Tiefenwert und ein Subject, das ein Zertifikat weiter oben in der Kette benennt. Es laufen zwei verschiedene Prüfungen, und nur eine davon betrifft das Endzertifikat. Der Vergleich erklärt, warum der Austausch des Serverzertifikats nichts ändert.

Welches Zertifikat der Prüfer tatsächlich abgelehnt hat

Eine Kette ist kein dreimal wiederholtes Objekt. Das Endzertifikat trägt Name und Schlüssel des Servers, die Zwischenzertifikate verbinden es mit einer Wurzel, und jedes hat seine eigene Gültigkeitsdauer, Einschränkungen und Verwendungen. Wenn der Fehler eine Tiefe nennt, bezeichnet diese Zahl eine Position in der Kette, die der Prüfer aufgebaut hat, und das ist womöglich nicht die erwartete Position, wenn der Server eine unerwartete Kette sendet.

Lesen Sie die Felder des Zertifikats in dieser Tiefe statt des Zertifikats, das Sie für schuldig hielten. Fragen Sie die beiden Erweiterungen ab, die die Ausstellung einschränken, statt jedes Feld auszugeben, denn die Antwort liegt fast immer in einer von ihnen. Erweiterungsausgaben sind unbedenklich teilbar; private Schlüssel nie.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Ist das genannte Zertifikat eine Zwischen-CA, deren erweiterte Schlüsselverwendung etwas nennt, das nichts mit TLS-Serverauthentifizierung zu tun hat, folgt der Rest des Fehlers mechanisch. Die Kette kann nicht für den Zweck verwendet werden, den OpenVPN angefordert hat.

Zweck des Endzertifikats und Kettenrichtlinie sind zwei Prüfungen

Die Endzertifikatsprüfung stellt eine enge Frage: Erlaubt dieses Endentitäts-Zertifikat die Serverauthentifizierung für diesen Namen? Die Kettenprüfung stellt eine breitere: Darf jedes Zertifikat im Pfad diesem Zweck dienen? Eine Zertifizierungsstelle, die nur Clientzertifikate ausstellen darf, besteht ihre eigenen Signaturprüfungen und scheitert trotzdem an der zweiten Prüfung, weil der Pfad, den sie autorisiert, den Zweck nicht enthält, den die Anwendung braucht. Beide Prüfungen scheitern mit denselben Worten und haben völlig unterschiedliche Reparaturen.

Deshalb kann ein frisch ausgestelltes Endzertifikat, in jedem sichtbaren Feld korrekt, sofort scheitern. Deshalb gehört die Korrektur meist in das Profil der ausstellenden Stelle und nicht in die VPN-Konfiguration.

Ein fehlendes EKU ist kein einschränkendes EKU

RFC 5280 macht die Erweiterung für erweiterte Schlüsselverwendung optional und, wenn vorhanden, einschränkend. Ein CA-Zertifikat ohne die Erweiterung hat daher kein „Nein“ zur Serverauthentifizierung gesagt, während eines, das nur einen sachfremden Zweck auflistet, etwas sehr Bestimmtes gesagt hat. Diese beiden Zustände als gleichwertig zu behandeln führt zur falschen Diagnose und, schlimmer, zur falschen Reparatur. Der Unterschied erklärt auch, warum zwei Stellen, die in einer Konsole ähnlich aussehen, sich in einer Kette völlig unterschiedlich verhalten.

Auch das Verhalten der Bibliotheken ist hier nicht einheitlich. Dokument von OpenSSL zu den Verifikationsoptionen beschreibt die eigene Behandlung von Zweckprüfungen bei CA-Zertifikaten, und diese Behandlung ist eine Implementierungsrichtlinie und keine Regel, der jeder TLS-Stack identisch folgt. Beschreiben Sie, was Ihr Prüfer tut, und bestätigen Sie es dann an der Version, die Sie tatsächlich ausführen.

Reproduzieren Sie den Fehler offline, bevor Sie neu ausstellen

Eine Offline-Prüfung nimmt die Anwendung aus der Frage heraus. Scheitert die Kette unter demselben Zweck auf dieselbe Weise, liegt das Problem am Zertifikat, und keine Serverkonfiguration verbirgt es. Besteht die Kette offline, während der Dienst weiter ablehnt, fordert die Anwendung einen anderen Zweck an oder verwendet eine andere Kette als die getestete.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain ist wichtig, weil es den Pfad ausgibt, den das Werkzeug aufgebaut hat, und der ist oft nicht die Dateireihenfolge, die Sie angegeben haben. Diese Ausgabe ist der schnellste Weg herauszufinden, dass ein zweites Zwischenzertifikat aus einem Truststore gezogen wird, dass der Server eine kreuzsignierte Variante sendet, die Sie nicht beabsichtigt haben, oder dass das aus einem Tutorial kopierte Zweck-Flag zu einer anderen Rolle gehört als der bedienten.

Korrigieren Sie die Ausstellungsrichtlinie, nicht den Prüfaufruf

Die dauerhafte Reparatur ist ein Zwischenzertifikat, das unter einer Richtlinie ausgestellt wurde, die die zu erfüllenden Zwecke erlaubt, mit schriftlich festgehaltener und geprüfter Einschränkung. Jeden Zweck zu jeder Stelle hinzuzufügen ist keine Richtlinie; es entfernt die Einschränkung, die die Erweiterung überhaupt sinnvoll machte, und überlebt meist den Vorfall, der es ausgelöst hat. Eine kurze Notiz im Profil, welche Rollen die Stelle zertifizieren darf, verhindert, dass die nächste Neuausstellung dieselbe Diskussion wiederholt.

Die Prüfung abzuschalten ist die andere verlockende Abkürzung, und sie verwandelt ein Zertifikatsproblem in ein Vertrauensproblem. Lassen Sie die Zweckprüfung bestehen, korrigieren Sie die Kette und führen Sie dieselbe Offline-Prüfung erneut aus, um zu bestätigen, dass der Pfad nun die vorgesehene Rolle bedient, bevor Sie den Dienst wieder anfassen.