OCSP Responder in der DMZ

Setzt man sich mit der Planung und Implementierung einer (möglicherweise Multi-Tier-) Enterprise-CA unter Windows auseinander, so wird man feststellen, dass hierfür sowohl ein CRL-Webserver (Certificate Revocation List) als auch ein OCSP Responder (Online Certificate Status Protocol) sinnvoll sind. In größeren Umgebungen befinden sich sowohl der CRL-Webserver als auch der OCSP Responder meistens in einer DMZ und sind weder Mitglied der selben noch Mitglied einer vertrauten Domäne der Issuing Certificate Authority (dt. Zertifizierungsstelle).

Im Gegensatz zu einer herkömmlichen Zertifikatssperrliste (CRL), welche komplett digital signiert von der Zertifizierungsstelle kommt, werden OCSP Anfragen pro Antwort signiert. Dafür wird ein OCSP Response Signing Zertifikat benötigt, welches nur kurze Laufzeiten haben sollte, da dies die Zertifikatserweiterung „id-pkix-ocsp-nocheck“ beinhaltet und so keinerlei Revocation Check erfolgt.

Die folgende Grafik beschreibt den Ablauf eines OCSP-Checks:

Steht der OCSP Responder (ggf. mehrere hinter einem Load Balancer) nun in einer DMZ, hat dieser keinerlei Möglichkeit, ein solches Zertifikat automatisch bei einer CA anzufordern. Dadurch gibt es für die Automatisierung dieses Vorganges auch keine Best Practice. Allerdings konnte uns auch hier PowerShell wieder aushelfen.

Das Script „Renew-OCSPResponderCertificate.ps1” (zu finden auf Github) übernimmt das automatische Anfordern eines OCSP-Signing-Zertifikats für eine oder mehrere Enterprise-CAs und OCSP-Responder-Server. Hierfür wird eine PowerShell Remoting (WinRM) Verbindung zu den Servern genutzt, welche die OCSP-Responder-Rolle (z.B. in der DMZ) hosten. Seitens der OCSP Responder Server wird ein Service-Account benötigt, welcher die Rechte hat, den lokalen Computer-Zertifikatsspeicher zu nutzen und zu bearbeiten, um darüber Zertifikatsanforderungen auszustellen und abzuschließen. Außerdem muss dieser mindestens die Rechte haben, die Windows Remote Management Schnittstelle zu bedienen, eine passende lokale Gruppe dafür ist z.B. Remote Management Users (dt. Remoteverwaltungsbenutzer).

Um die Zertifikatsanforderung abzuschließen, wird ein weiterer Service Account (ggf. Domainbasiert) mit Windows Remote Management Berechtigungen auf einem System in der Domäne der entsprechenden Enterprise CA benötigt. Hierfür kann z.B. auch eine direkte Verbindung auf den Server, welcher die Enterprise CA hostet, genutzt werden. Der erwähnte Service Account benötigt außerdem die Rechte, Zertifikate mit der entsprechenden OCSP Signing Vorlage anzufordern.

Der Job, der dieses Script ausführt, sollte bereits einige Tage vor Ablauf des alten Zertifikates ausgeführt werden.

Beispiel: Hat die OCSP Responder Zertifikatsvorlage eine Laufzeit von 14 Tagen, so sollte man nach Möglichkeit den Job im Intervall von 10 Tage laufen lassen.

Das Script führt also die folgenden Schritte pro OCSP Responder Definition aus:

• Aufbau einer PowerShell Remoting Session zum OCSP Responder
• Ausstellen einer Zertifikatsanforderung (CSR) pro definierter Enterprise CA mit „certreq.exe“
• Kopieren der CSR Files in die Workfolder des Scriptes
• Pro CA:
  • Aufbau einer PowerShell Remoting Session zum WinRM Jumphost in der Domäne der CA
  • Kopieren der jeweiligen CSR Datei auf den WinRM Jumphost
  • Abschließen der Zertifikatsanforderung mit „certreq.exe“
  • Kopieren des signierten Zertifikates auf den jeweiligen OCSP Responder Server über die Workfolder des Scriptes
  • Import der abgeschlossenen Zertifikatsanforderung auf dem OCSP Responder Server „certreq.exe“
  • Hinzufügen der Berechtigung für den „NETWORK SERVICE“ auf den Private Key des Zertifikates (notwendig für Zugriff des OCSP Responder IIS Pools)
  • Entfernen aller bereits abgelaufenen Zertifikate auf dem OCSP Responder Server

Da der Private Key des Zertifikates den jeweiligen OCSP Responder nicht verlässt, ist diese Methode auch aus sicherheitskritischer Sicht in Ordnung.

Konfiguriert man den OCSP Responder Service mit der „automatischen OCSP Signing Zertifikatsauswahl“, so wird dieser das neue Zertifikat auswählen, sobald das alte abgelaufen ist. Bei einem manuellen Neustart des OCSP Responders, wird automatisch das Zertifikat mit der längsten Laufzeit gewählt.