OCSP: auf POST Request folgt 405 Method Not Allowed
Frage
Alle Antworten
-
Hallo mslux,
ist dieser Thread noch aktuell? Bist Du hier inzwischen weitergekommen?
Gruss,
Alex -
Vielen Dank Tobias! Der Technet-Artikel ist sehr lang und wirklich sehr ausführlich. Es gibt ihn aúch auf deutsch. Nur leider habe ich alles so konfiguriert, wie in dem Artikel beschrieben. In meiner Testinstallation läuft es ja auch, nur in der Produktivumgebung nicht.
Dass die CryptoAPI 2.0 zuerst die GET-Methode benutzt kann ich nicht nachvollziehen. Wenn ich mit dem Internet Explorer oder mit der Remotedektopverbindung eine SSL-Kommunikation aufbaue kann ich mit dem Sniffer keinen OCSP-Datenverkehr feststellen. Die Verbindungen werden fehlerfrei hergestellt. Auch das Abfragen der CRL ist nicht feststellbar. Im oben angegebenen CryptoUrlCache tauchen aber 21 Dateien auf, alle im Binärformat.
Teste ich mit certutil -url oder mit Firefox ist bei beiden die OCSP-Kommunikation sichtbar, sie beginnt aber nicht mit GET sondern gleich mit POST und wird vom Server abgelehnt. Erzwinge ich bei Firefox die OCSP-Prüfung kommt keine Verbindung zu Stande, Fehler: "Der OCSP-Server hat unerwartete/ungültige Daten geliefert. (Fehlercode: sec_error_ocsp_bad_http_response)"
Im Network Monitor sehe ich diese Anfrage:
Daraufhin sendet der Server folgende Antwort:
Ein Proxy ist nicht dazwischen, die Firewall filtert kein POST heraus, sonst würde eine Webanwendung auf dem IIS auch nicht funktionieren.
Die URL /ocsp ist erreichbar, ein Versuch sie im Browser aufzurufen wird aber natürlich mit 403 beantwortet, da keine Startseite vorhanden ist. Es handelt sich ja auch um eine Anwendung.
Was meinst du mit "Was bringt eine Verifizierung mittels dem OCSP-Snap-In der konfigurierten URLs?" Im Snap-In ist alles grün. Wie kann man damit URLs verifizieren?
Im Anwendungsprotokoll tauchen nur Informationsereignisse auf, wie Dienst beendet, Dienst gestartet oder Webproxy ge- bzw. entladen.
Das Setzen des LogLevels auf 4 bewirkt nichts. Es gibt auch kein Dienstprotokoll unter %windir%\ServiceProfiles\networkservice\ocspsvc.log, obwohl laut dem Technetartikel dort eins sein soll.
Ich habe keine Idee mehr.
-
Nun habe ich das Protokoll Betriebsbereit unter Anwendungs- und Dienstprotokolle, Microsoft, Windows, CAPI2 aktiviert.
Dann habe certutil -url Webserver.cer aufgerufen, und OCSP abgerufen. Status: (wie immer) Gescheitert.
Im o. a. Protokoll steht:
Im Technetartikel Troubleshooting PKI Problems on Windows Vista wird jedoch auch nur wiederholt, was wir schon auf x anderen Webseiten gelesen haben:
If the HTTP method used to request information from the server is not
allowed by the server, HTTP status code "405" is returned to indicate
this error. This can be queried by looking for httpStatusCode
field with value "405" in "CryptRetrieveObjectByUrlWire" event. An
example of this scenario is when CAPI2 makes a request for an OCSP
response. CAPI2 first tries a GET method, and if the GET fails, then the POST method is used. If the server does not support POST, it will return an "HTTP 405" error.Alle Diagnosen beweisen jedoch, dass das zumindest bei certutil nicht so ist! Selbst auf meinem Testsystem fragt certutil mit der POST-Methode ab. Dort erhält er aber HTTP/1.1 200 OK! Es wird zwar auch ein Fehler bei der Ereignis-ID 53 angezeigt, jedoch ist hier die Ursache, dass keine PAC-URL gefunden wurde. Im gleichen Ereignis wird aber Result 0 angezeigt. certutil meldet den Status Überprüft.
Das bringt mich zurück zu meiner ursprünglichen Frage: Wie kann ich dem Online-Responder die Methode POST erlauben? Meine Vermutung ist, es liegt am Webserver oder an der Webproxy-Komponente des Online-Responders.
-
certutil verwendet weiter die POST-Methode. Das war ja auch schon bei meinem Testsystem so. Hier der Beweis (Aufzeichnung mit Wireshark):
POST /ocsp HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: application/ocsp-request Accept: */* User-Agent: Microsoft-CryptoAPI/6.1 Content-Length: 77 Host: unserWebServer.domain.tld HTTP/1.1 200 OK Cache-Control: max-age=50555 Content-Length: 1501 Content-Type: application/ocsp-response Expires: Sat, 25 Aug 2012 14:27:50 GMT Last-Modified: Fri, 24 Aug 2012 02:07:50 GMT ETag: "cab0a3347980f05c3651dd484f3e6e9a" Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Fri, 24 Aug 2012 14:00:26 GMT
Das Snap-In pkiview.msc verwendet jetzt zuerst die GET-Methode. Das war auch bei meinem Testsystem schon immer so, nur beim Produktivsystem leider nicht.
Firefox verwendet auch die POST-Methode:
POST /ocsp HTTP/1.1 Host: unserWebServer.domain.tld User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive Content-Length: 109 Content-Type: application/ocsp-request Cookie: AspxAutoDetectCookieSupport=1 HTTP/1.1 200 OK Cache-Control: max-age=50555 Content-Length: 1501 Content-Type: application/ocsp-response Expires: Sat, 25 Aug 2012 14:27:50 GMT Last-Modified: Fri, 24 Aug 2012 02:07:50 GMT ETag: "cab0a3347980f05c3651dd484f3e6e9a" Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Fri, 24 Aug 2012 14:08:25 GMT
Thunderbird verwendet auch die POST-Methode (getestet über POP3S).
Der Internet Explorer 9 macht überhaupt kein OCSP. Er bekommt die Gültigkeit während des SSL-Handshakes vom Server mitgeteilt ohne je danach gefragt zu haben (es gibt zu dieser Response also keinen Request).
Opera verhält sich genau wie der IE.
mstsc hat bei meinem Test überhaupt keine Gültigkeitsabfrage gemacht. Das kann aber daran liegen, das im lokalen Cache noch die Antwort des IEs liegt und beide Dienste das gleiche Zertifikat verwenden.
