<tt>Hallo Zusammen,</tt>
wir <tt>betreiben derzeit eine eigene interne dreistufige PKI auf Basis Windows 2012 R2 für Geräte- und Nutzer-Zertifikate - das Ganze unter einer gemeinsamen</tt> <tt>Root- und Policy-CA.</tt>
<tt>Im Rahmen der Zertifikatsnutzung werden auch Sperrinformationen über OCSP (primär) und</tt><tt>CRL
(backup) durch die PKI Clients geprüft.</tt> <tt>Die Sperrlisten der Root- und Policy-CA (offline CAs, non AD) haben eine Gültigkeit von maximal 180 Tagen (nextUpdate). Die Sperrlisten der Issuing-CAs
(hier Device- und User-CA im AD) haben eine Gültigkeit von maximal 7 Tagen (nextUpdate). Der eingesetzte OCSP Responder (auf Basis W2k12 R2) gibt Onlinestatusinformationen zu den Zertifikaten aus und steht als Stand-Alone Lösung in einem isolierten Netzwerkbereich.</tt><tt>Die OCSP Antworten werden auf Basis der aktuellen Sperrlisten (CRLs) der jeweiligen Issuing CA erzeugt. Die Sperrlisten werden auf dem Webserver</tt>, <tt>der
gleichzeitig auch OCSP-Responder ist, abgelegt. Das OCSP Modul bezieht in seiner Sperrkonfiguration die CRL alle 5 Minuten vom einem virtuellen Verzeichnis des lokalen Webservers und</tt> <tt>generiert
daraus OCSP-Antworten.</tt>
<tt>Es scheint jedoch ein Problem in der aktuellen OCSP Implementierung und dem IIS zu geben:</tt>
<tt>1. Wird eine neue Sperrliste (mit einem gesperrten Zertifikat) vor Ablauf der 7 Tage erzeugt und veröffentlicht, wird diese vom OCSP Responder zwar nach der eingestellten Zeit (hier
5 Minuten) aus der Sperrkonfiguration angefragt, aber NICHT GELADEN und zur Erzeugung von OCSP-Antworten verwendet. Das Resultat - ein gesperrter Nutzer kann sich bspw. weiterhin per Smartcard Logon anmelden.</tt>
<tt>2. Wird der OCSP Responder in seiner Console manuell getriggert (über Sperrdaten aktualisieren) funktioniert die OCSP Statusauskunft einwandfrei.</tt>
<tt>3. Wird im Anschluss ein gesperrtes (onHold) Zertifikat wieder entsperrt, erfolgt auch in diesem Fall keine Aktualisierung der OCSP Statusinformationen nach 5 Minuten (das Zertifikat
ist weiterhin gesperrt).</tt>
<tt>4. Wird der OCSP Responder wieder manuell aktualisiert ist die Auskunft wieder korrekt.</tt>
<tt>Aus dem IIS Logfile ist ersichtlich, dass beim manuellen Refresh die Sperrliste vom Webserver geladen wird und ein http Error 200 (OK) protokolliert wird.</tt><tt>Wird der Refresh nicht manuell getriggert sondern über die zeitliche Aktualisierung (alle 5 Minuten) wird ein Error 304 (Not Modified) ausgegeben, auch</tt> <tt>wenn
die Sperrliste in der Zwischenzeit durch eine neue überschrieben wurde.</tt>
<tt>Kennt jemand das Problem?</tt>Gibt es ggf. ein Workaround oder Fix?
<tt>Wie kann das OCSP Modul bzw. den IIS so einstellen, dass eine Sperrliste, die neuer ist und andere Daten enthält vom OCSP Modul korrekt geladen</tt><tt>wird und im Anschluss die PKI Client korrekt bereitstellt?</tt>
Danke vorab an alle für die Unterstützung.