Benutzer mit den meisten Antworten
OCSP: auf POST Request folgt 405 Method Not Allowed

Frage
-
Hallo,
ich bekomme den Online Responder nicht zum Laufen. Sowohl pkiview.msc als auch certutil -url melden Fehler bei OCSP.
In den AIA habe ich zwei HTTP-URLs eingetragen. Sie erscheinen auch in ausgestellten Zertifikaten. Nun habe ich die Kommunikation mit dem MS Network Monitor untersucht. Ergebnis: Der Client fragt die OCSP-URLs mit der POST-Methode ab, der IIS antwortet mit 405 Method Not Allowed. Erlaubt seien nur GET, HEAD, OPTIONS und TRACE.
In der Anforderungsfilterung ist weder auf Serverebene, noch bei der Standardwebsite noch bei der Anwendung "ocsp" etwas eingetragen. Damit müssten alle Methoden erlaubt sein. Ein expliziertes Zulassen von POST bei "ocsp" bewirkt nichts, die Fehlermeldung bleibt.
Auf einer Testinstallation habe ich versucht die Situation nachzustellen - aber dort funktioniert alles. Ein Vergleich der IIS-Einstellungen zwischen funktionierender und fehlerhafter Umgebung brachte keine Lösung.
Wie kann ich dem Online Responder die Methode POST erlauben?
- Typ geändert Raul TalmaciuMicrosoft contingent staff Donnerstag, 23. August 2012 07:14 Warten auf Feedback
- Typ geändert mslux Donnerstag, 23. August 2012 10:25
Antworten
-
So Problem gelöst! Ursache war, dass in der applicationhost.config die Handlerzuordnungen für OCSP fehlten. Es wurden die der Standardwebsite vererbt, die natürlich keinen Bezug zur ocspisapi.dll hatten. Da man im IIS-Manager keine Händler für eine Webanwendung eintragen kann, die im klassischen Anwendungspool läuft, habe einfach den Rollendienst Online-Responder deinstalliert, wieder neu installiert und eine neue Sperrkonfiguration angelegt.
Die Deinstallation entfernt übrigens nicht die Anwendung ocsp im IIS, was dann bei der Neuinstallation zur merkwürdigen Fehlermeldung "Datei nicht gefunden" führt. Erst im Protokoll des Server-Managers war ersichtlich, dass certitil -vocsproot fehlschlug. Ein manuelles Ausführen des Kommandos ergab dann die (sinngemäße) Fehlermeldung, dass eine Datei nicht erzeugt werden könne, wenn sie schon vorhanden sei.
Ich danke dir Tobias für deine Unterstützung!
- Als Antwort markiert mslux Freitag, 24. August 2012 12:27
Alle Antworten
-
Hintergrundinformationen hierzu:
When an application calls CryptoAPI 2.0 to verify a certificate that specifies locations to Online Responders, the revocation infrastructure performs the following basic steps (for each Online Responder specified in the authority information access extension):
- Search the local CryptoAPI 2.0 in-memory and disk caches to find a cached OCSP response that has a valid time. The disk cache is located at: <drive>:\Users\<User name>\AppData\LocalLow\Microsoft\CryptnetUrlCache.
- If no acceptable cached response can be found, a request is sent by using the HTTP GET method. In situations where the Online Responder does not support the GET method, CryptoAPI 2.0 will retry the request by using the HTTP POST method. Only one certificate can be validated per OCSP request. Moreover, it is not possible to configure CryptoAPI 2.0 to always try the POST method first.
Source: http://technet.microsoft.com/en-us/library/cc770413(v=ws.10).aspx
Evtl. ist ein Proxy/Firwall dazwiaschengeschalten, der die POST-Methode (und vorher schon die GET-Methode - s.o. Hintergrundinformationen) nicht zulässt?
Zusätzlich sollte die URL im Certificate für den OCSP verifiziert werden, ob diese wirklich dem zu erwarteten Host entspricht und dieser seitens des Client erreichbar ist.
Des Weiteren: Was bringt eine Verifizierung mittels dem OCSP-Snap-In der konfigurierten URLs?
Sind Events in der Ereignisanzeige bzgl. OCSP zu sehen?
Ggf. das Event-logging auf dem OCSP Server erhöhen:
HKLM\SYSTEM\CurrentControlSet\Services\OCSPSvc\Responder\LogLevel = 4
Source: http://technet.microsoft.com/en-us/library/cc468537.aspx
--
Tobias Redelberger
StarNET Services (HomeOffice)
Frankfurter Allee 193
D-10365 Berlin
Tel: +49 (30) 86 87 02 678
Mobil: +49 (163) 84 74 421
Email: T.Redelberger@starnet-services.net
Web: http://www.starnet-services.net -
Hallo mslux,
ist dieser Thread noch aktuell? Bist Du hier inzwischen weitergekommen?
Gruss,
AlexAlex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
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.
-
Aktuell ist mir nur dieses Verhalten bekannt:
Method Not Allowed by the Web Server
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.
Source: http://technet.microsoft.com/en-us/library/cc749296(v=ws.10).aspx#BKMK_MethodNotAllowed
Deswegen müsste man das exakte Verhalten und die zugrundeliegende Konfiguration genauer ansehen, welches jedoch besser durch ein Support-Call bei Microsoft geschehen sollte.
--
Tobias Redelberger
StarNET Services (HomeOffice)
Frankfurter Allee 193
D-10365 Berlin
Tel: +49 (30) 86 87 02 678
Mobil: +49 (163) 84 74 421
Email: T.Redelberger@starnet-services.net
Web: http://www.starnet-services.net- Bearbeitet Tobias Redelberger Dienstag, 21. August 2012 15:33
- Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 22. August 2012 09:51
- Nicht als Antwort vorgeschlagen mslux Mittwoch, 22. August 2012 10:01
-
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.
-
So Problem gelöst! Ursache war, dass in der applicationhost.config die Handlerzuordnungen für OCSP fehlten. Es wurden die der Standardwebsite vererbt, die natürlich keinen Bezug zur ocspisapi.dll hatten. Da man im IIS-Manager keine Händler für eine Webanwendung eintragen kann, die im klassischen Anwendungspool läuft, habe einfach den Rollendienst Online-Responder deinstalliert, wieder neu installiert und eine neue Sperrkonfiguration angelegt.
Die Deinstallation entfernt übrigens nicht die Anwendung ocsp im IIS, was dann bei der Neuinstallation zur merkwürdigen Fehlermeldung "Datei nicht gefunden" führt. Erst im Protokoll des Server-Managers war ersichtlich, dass certitil -vocsproot fehlschlug. Ein manuelles Ausführen des Kommandos ergab dann die (sinngemäße) Fehlermeldung, dass eine Datei nicht erzeugt werden könne, wenn sie schon vorhanden sei.
Ich danke dir Tobias für deine Unterstützung!
- Als Antwort markiert mslux Freitag, 24. August 2012 12:27
-
Danke fürs Feedback :)
Aus Interesse: wird weiterhin - nach Neuinstallation des OCSP - zuerst mit POST die Abfrage initiiert, oder wird nun auch wieder zuerst die Anfrage mit der GET-Methoder verfolgt?
--
Tobias Redelberger
StarNET Services (HomeOffice)
Frankfurter Allee 193
D-10365 Berlin
Tel: +49 (30) 86 87 02 678
Mobil: +49 (163) 84 74 421
Email: T.Redelberger@starnet-services.net
Web: http://www.starnet-services.net -
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.