Verwenden von HTTP über Transport Layer Security (HTTPS) für die Sperrlistenverteilungspunkte (CDP) und den Onlineresponder (OCSP)

In Hinsicht auf die Gestaltung der Infrastruktur zur Bereitstellung der Sperrinformationen – also der Sperrlistenverteilungspunkte (CRL Distribution Point, CSP) sowie der Online Responder (Online Certificate Status Protocol, OCSP) kommt die Frage auf, ob man diese über Secure Sockets Layer (SSL) bzw. Transport Layer Security (TLS) "absichern" sollte.

Mitunter ist es erforderlich, dass ein von einer Zertifizierungsstelle ausgestelltes Zertifikat bereits vor dessen Ablaufdatum aus dem Verkehr gezogen werden muss. Um dies zu ermöglichen, hält eine Zertifizierungsstelle eine Sperrliste vor. Hierbei handelt es sich um eine signierte Datei mit einem relativ kurzen Ablaufdatum, welches in Kombination mit dem Zertifikat zur Überprüfung der Gültigkeit herangezogen wird.

Der Online Responder (Online Certificate Status Protocol, OCSP) ist eine alternative Möglichkeit, Sperrstatusinformationen für Zertifikate bereitzustellen. Entitäten, die den Sperrstatus eines Zertifikats überprüfen möchten, müssen dank OCSP nicht die komplette Liste aller widerrufenen Zertifikate herunterladen, sondern können gezielt eine Anfrage für das betreffende Zertifikat an den Online Responder stellen. Für eine detailliertere Beschreibung siehe Artikel "Grundlagen Online Responder (Online Certificate Status Protocol, OCSP)".

Oft sind Unternehmen auch aufgrund von Compliance-Richtlinien angehalten, alle HTTP-basierten Verbindungen über SSL/TLS abzubilden. Somit kommt auch die Frage auf, ob und wie dies für die CDPs oder OCSP umgesetzt werden sollte, da beide Methoden auf unverschlüsseltes und somit vermeintlich unsicheres HTTP setzen.

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Um diese Frage zu beantworten, werfen wir zunächst einen Blick in die einschlägigen RFCs zu diesem Thema. Für die Sperrlistenverteilpunkte wäre dies das RFC 5280:

When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies. CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server’s certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server’s certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Für das Online Certificate Status Protocol finden wir die entsprechende Passage im RFC 6960:

Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol.

RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP

Fazit

Beide RFCs verbieten nicht, SSL/TLS zu verwenden. Das RFC 5280 warnt jedoch explizit davor. Der Grund ist folgender:

Setzt man SSL/TLS für die Sperrinformationen ein, benötigt man ein entsprechendes Zertifikat. Dieses wird wiederum Sperrinformationen beinhalten, die geprüft werden müssen, damit das Zertifikat als gültig anerkannt werden wird.

Damit schafft man sich eine (möchte man durchgehend SSL/TLS einsetzen) nicht auflösbare Abhägigkeit. Die einzige Möglichkeit, diese aufzulösen ist, dass der letzte Sperrlistenverteilungspunkt in der Kette wieder ohne HTTPS abgebildet wird.

Somit entfallen die vermeintlichen Vorteile von HTTPS in diesem Fall.

Da die Sperrinformationen sowohl bei der Verwendung von Sperrlisten als auch OCSP jedoch ohnehin durch die Zertifizierungsstelle bzw. den Onlineresponder signiert und somit vor Manipulation geschützt sind, gibt es aber auch abseits des Problems mit den unauflösbaren Abhängigkeiten keinen Grund für den Einsatz von HTTPS in diesem Fall.

Weiterführende Links:

Externe Quellen

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
• RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP (Internet Engineering Task Force)