403.7 IIS 7.5 SSL-client-Zertifikat-Authentifizierung Frage

Ich bin testen eines web service mit einem externen partner mit 2-Wege-SSL unter IIS 7.5. Ich bin erfordert SSL, erfordern ein client-cert, und mit eins-zu-eins-Zuordnung zur Authentifizierung an einer Domäne Konto. Ich habe alles konfiguriert und es funktioniert gut auf unser Netzwerk (ich bin in der Lage, eine client-cert, authentifiziert und ruft den service von browser-und Testumgebung).
Von außerhalb unseres Netzwerks (in den meisten Fällen, siehe unten), ich bin immer ein 403.7-Fehlermeldung. Ich habe gegangen durch die Maschine-level-Zertifikat zu speichern und sorgte dafür, dass die Zertifikate und Zertifizierungsstellen sind Vertrauenswürdige.
Hier ist die seltsame Sache. Ich erhielt eine Typ-I-cert zum testen zu Hause (und habe 403.7 wie unsere partner bestimmt ist). Also richte ich Fiddler Debuggen von SSL und schicken Sie mir das Zertifikat, und dieses funktioniert aus irgendeinem Grund. Ich setup eine Testumgebung zu übergeben, die genau die gleiche Zertifikat, und bekam 403.7. Ich Teste in meinem browser (IE 9), nicht bekommen, eine Eingabeaufforderung für einen client-cert, und erhalten Sie 403.7.

Jede Hilfe zu schätzen.
Bill

InformationsquelleAutor Bill | 2011-05-25
  1. 8

    Letzte mal habe ich geprüft, IIS war mit re-negotiation (standardmäßig), um das client-Zertifikat: es gibt einen ersten händedruck, wo der server nicht Anfrage eines client-Zertifikats, gefolgt von einem handshake (verschlüsselt dieser Zeit), wobei der server das Zertifikat anfordert (über eine TLS - CertificateRequest Nachricht). Dadurch wird verhindert, dass Sie sehen, alles von Wireshark, es sei denn, Sie konfigurieren es zur Nutzung der server den privaten Schlüssel und entschlüsseln Sie den Verkehr (beachten Sie, dass dies funktioniert nur mit einige cipher suites).

    Einen Weg, um zu sehen, das client-Zertifikat Verhandlung ist zum konfigurieren von IIS für die Verwendung von initial-client-Zertifikat-Aushandlung mit netsh und clientcertnegotiation=true (die über ersten Verhandlung). Zumindest die CertificateRequest und das Zertifikat wird gesendet, in klaren, die während des Handshakes, so dass Sie sollten in der Lage sein zu sehen, diese mit Wireshark.
    Wenn der client nicht senden ein Zertifikat auf dem server als Reaktion auf die CertificateRequest haben, werden Sie noch sehen, ein leeres Certificate Nachricht vom client.

    Wenn Sie nicht exportieren Sie den privaten Schlüssel mit dem Zertifikat zu verwenden, mit Fiddler oder welche anderen Kunden, es gibt keine chance, dass er in der Lage sein, das Zertifikat zu verwenden. Es kann bestenfalls versuchen, senden Sie das Zertifikat, aber der handshake schlägt fehl (da die CertificateVerify Nachricht muss signiert werden, indem der client den privaten Schlüssel).

    Ich denke, man kann das auf ein problem stoßen, wobei:

    • nicht präsentiert, ein Zertifikat wird akzeptiert, indem der server (es ist effektiv optional),
    • präsentiert ein ungültiges Zertifikat macht es nicht und die Ursachen dieser 403.7-status-code (viele Server-und SSL - /TLS-stacks implementieren würden dies als ein schwerwiegender Fehler, aber TLS-Spezifikation nicht sagen, dass unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown sollte tödlich sein, so ist dies bei der server-Wahl).
    • Gute Beratung. Ich vergaß, wir liefen mit clientcertnegotiation=true bei der Verwendung von WS 🙂
    • Ich war in der Lage, um die SSL-Entschlüsselung mit Wireshark. Was ich sehe, in unserem Netzwerk ist eine Zertifikat-Anfrage-Nachricht zu dem client nach dem zweiten handshake. Dies geschieht nicht außerhalb unseres Netzwerks (kein Zertifikat-Anfrage wird vom server gesendet, nachdem die zweite handshake. Was gesendet wird, ist: Server Hello, Certificate). Nochmals vielen Dank für das Lesen und reagieren.
    • Im Falle dass es war nicht klar, von oben, das ist immer noch ein offenes problem. Mein Verdacht jetzt drehen die Richtung entweder die firewall oder die Liste der Zertifizierungsstellen wird zurückgegeben, in den Zertifikat-Anfrage (trotz der Tatsache, dass ich bin nicht zu sehen, eine Zertifikat-Anfrage außerhalb unseres Netzwerks, bemerkte ich, dass die Liste von CAs in der Anforderung enthalten sind, die auf das interne Netzwerk war nicht die komplette Liste habe ich konfiguriert in dem computer speichern. Nicht sicher, warum.)
    • OK, herausgefunden mein problem. Zuerst, ich weiß nicht, warum ich nicht sehen, eine Zertifikat-Anfrage in Wireshark, denn ich sehe jetzt, dass die Dinge funktionieren, und ich bin sicher, man war ausgestellt vor, weil ich habe das cert-Eingabeaufforderung w/ ein anderes cert gelistet. Also ich halte das für eine falsch-negative. Ich hatte zum ändern der Dienst zum ausführen unter einem Konto mit Berechtigungen, um das Zertifikat zu speichern und NTFS-Ordner. Meine client-cert nutzt ein Vermittler CA, so musste ich hinzufügen, dass der server-Computer zu speichern. Letzte Ausgabe war die root-CA für meine client-cert importiert w/o die client-Authentifizierung verwenden, angezeigt.
    InformationsquelleAutor Bruno
  2. 0

    Sind Sie mit den gleichen physikalischen Maschine zu testen, sowohl die in-Netzwerk und externen Netzwerk-verbindungen? Wenn nicht, sind Sie sicher, dass die externen-Netzwerk-client den privaten Schlüssel zugänglich?

    Habe ich nicht konfiguriert Fiddler client-Authentifizierung vor. Funktioniert Lesen Sie das client-Zertifikat und den Schlüssel aus dem standard-Zertifikat-stores? Tut es direkt aus einer PKCS12?

    Eine andere Sache, die hilfreich sein können, die Sie inspizieren, der TLS-handshake in WireShark. Überprüfen Sie speziell die Server "Certificate Request" - Meldung, da die Daten hier Hinweise, die der client (IE9), die client-Zertifikate angezeigt werden soll in der Eingabeaufforderung. Vergleichen Sie diese für die internen und externen verbindungen.

    • Vielen Dank für die Beratung. Fiddler verwendet einfach ein .cer-Datei, die Sie in der MyDocuments-Ordner unter einem festen Namen. Ich habe nicht einbetten der private Schlüssel in die cert-Datei, aber es schien nicht zu stören, Fiddler ' s-Verbindung. Ich werde versuchen, Ihre Wireshark Idee, obwohl ich habe nie sah den TLS-handshake vor. Ein Verdacht, den ich habe, ist, dass unser wildcard-Zertifikat auf dem server kann das irgendwie Auswirkungen auf die Zertifikat-Abfrage, aber bei Fiddler ' s proxy server request-cert, kann es sein, arbeiten und dann Fiddler geht das cert auf dem server unabhängig. Nochmals vielen Dank.
    InformationsquelleAutor jglouie
Schreibe einen Kommentar