Kann ein beliebiges SSL-Zertifikat zur Authentifizierung von Client-Zertifikaten verwendet werden?

820
Athul k Surendran

Ich versuche, eine Verbindung zu einer API eines Drittanbieters herzustellen, für die die gegenseitige Einrichtung der TLS-Authentifizierung aktiviert ist. Ich sollte also meine Client-Zertifikate in meinem Schlüsselspeicher installieren und an den TLS-Handshake-Prozess senden.

Für diesen Prozess verwende ich jetzt commodo positive SSL als clientseitiges Zertifikat. Wenn ich TLS-Aufrufe mache, obwohl der Server ein Zertifikat anfordert, sendet der Client kein Zertifikat. Und wenn ich SChannel Log überprüft habe, kann ich eine solche Warnung sehen

Der Remote-Server hat die TLS-Client-Authentifizierung angefordert, es konnte jedoch kein geeignetes Client-Zertifikat gefunden werden. Eine anonyme Verbindung wird versucht. Diese TLS-Verbindungsanforderung kann abhängig von den Richtlinieneinstellungen des Servers erfolgreich sein oder fehlschlagen.

SO bezweifle ich, dass ich den richtigen Typ des X509-Zertifikats für die clientseitige Authentifizierung verwende? Muss ich einen anderen spezifischen Typ verwenden? Da wird mein aktuelles Zertifikat nicht gesendet.

0

1 Antwort auf die Frage

1
grawity

Es hängt davon ab, ob. X.509v3-Zertifikate enthalten normalerweise ein Erweiterungsfeld "Extended Key Usage", das eine Liste der zulässigen Verwendungen (EKUs) enthält.

  • Normale Webserverzertifikate enthalten die Verwendung der "TLS- Serverauthentifizierung " (manchmal als "TLS-Webserver" bezeichnet, ist aber in Wirklichkeit nicht webspezifisch).

  • Um als Client zu fungieren, benötigen Sie ein Zertifikat mit "TLS-Client-Authentifizierung" (wird häufig als "TLS-Webclient" angezeigt, obwohl es nichts Webspezifisches enthält).

Es ist üblich, dass reguläre SSL-Zertifikate für "Webserver" beide Verwendungen enthalten. Ich betrachte zum Beispiel Zertifikate, die von Let's Encrypt und DigiCert ausgestellt wurden, und alle enthalten beide Verwendungen. Sie können daher für die Client- / gegenseitige Authentifizierung verwendet werden .

Es ist jedoch möglich, dass in einigen anderen Zertifizierungsstellen, insbesondere in privaten Organisationszertifizierungsstellen, die meisten Zertifikate die eine oder andere Verwendung haben, jedoch selten beides.

Beispielsweise forderte OpenVPN normalerweise " nur TLS-Client" (und nicht " mindestens TLS-Client" wie andere Programme). Daher gibt das easy-rsaSkript nur Serverzertifikate und nur Clientzertifikate aus, jedoch nicht die gemischte Art.


Daher sollten Sie Ihre Zertifikate prüfen und sicherstellen, dass sie die erforderliche EKU enthalten. Praktisch wird jedes Zertifikat - Tool die Arbeit erledigen - zum Beispiel der Zertifikateigenschaften zeigen in Windows - Dialog diese unter „V3 Extensions“, ebenso wie Web - Browser, openssl x509, certtool, certutiletc.

Denken Sie auch daran, wenn Sie Ihre eigene interne Zertifizierungsstelle betreiben: Wenn Sie ein Zwischenzertifizierungsstellenzertifikat verwenden, achten Sie auch darauf. Zwischenprodukte müssen nicht über eine EKU-Erweiterung verfügen. Wenn dies jedoch der Fall ist, sind alle von diesem Zwischenprodukt ausgestellten Zertifikate davon abhängig. (Wenn Sie die Zertifikate im Handel erwerben, müssen Sie sich nicht darum kümmern.)


Darüber hinaus enthält das Zertifikat ein grundlegendes Feld "Schlüsselverwendung", das einige sehr allgemeine Einschränkungen enthält: zB "Digitale Signatur" bedeutet, dass das Zertifikat Daten signieren darf (und daher EDH / EECDH-Handshake in TLS erlaubt). "Schlüsselvereinbarung" scheint für statische DH / ECDH zu gelten; "Schlüsselverschlüsselung" ermöglicht statische RSA-Handshakes.

Die offizielle X.509v3-Dokumentation ist sehr verwirrend in Bezug auf die Verwendungszwecke, wenn ... Professionelle Zertifizierungsstellen dieses Feld normalerweise verwenden. Für private Zertifizierungsstellen lohnt es sich jedoch, dies zu überprüfen.

EKU zeigt beide Optionen für mich (Serverauthentifizierung (1.3.6.1.5.5.7.3.1) Clientauthentifizierung (1.3.6.1.5.5.7.3.2)) Danke Athul k Surendran vor 6 Jahren 0
Dann sollte das Zertifikat gut sein. (Überprüfen Sie jedoch die Zwischenkette nur für den Fall.) Das Problem könnte in Ihrer Software liegen, z. B. haben Sie das cert an einer falschen Stelle installiert oder Sie haben den privaten Schlüssel (.pfx-Datei) nicht installiert? grawity vor 6 Jahren 0
Ich verwende ein Zertifikat von COmodo CA. Ich hoffe, es ist für meinen Fall egal Athul k Surendran vor 6 Jahren 0
Der Name der CA spielt keine Rolle. Das bitte ich Sie nicht zu überprüfen. grawity vor 6 Jahren 0
OK. Mein Verständnis war, wenn ich kommerzielles CA (Comodo) verwende, sollte ich die Kette nicht überprüfen. Aber werde es jetzt trotzdem überprüfen. Oder wenn mir etwas fehlt, erklären Sie mir bitte mehr Athul k Surendran vor 6 Jahren 0
Und ja, ich habe versucht, ein Zertifikat an jedem Ort im Geschäft zu installieren und .pfx habe den Schlüssel, den ich bestätigen kann. Mit mehr Details habe ich tatsächlich eine neue Frage gestellt, da der Zweck dieser Frage nicht darin bestand, mein Problem sofort zu lösen. https://superuser.com/questions/1296931/certificate-request-and-the-certificate-available-in-store-not-matching nicht Athul k Surendran vor 6 Jahren 0