Wir erhalten häufig Fragen zur Anwendung von Richtlinien, die es CAs erlauben, nur bestimmte Arten von Zertifikaten oder Zertifikate, die nur in ganz bestimmten Anwendungsfällen verwendet werden können, auszustellen. Eine immer häufiger gestellte Frage ist, wie man Proxy- oderSSL Intercept-Anwendungen von Drittanbietern wie Zscaler, F5 oder Palo Alto einschränken bzw. "sperren" kann.
Warum soll das Zertifikat eingeschränkt werden?
Eine SSL Intercept-Anwendung fungiert als Man-in-the-Middle-Anwendung, die Echtzeitzertifikate ausstellen will, die vorgeben, die Ziel-Webserver zu sein. Diese ermöglichen eine autorisierte Überwachung von SSL Verbindungen. Diese Anwendungen erstellen ihre eigenen CSRs, die ein Sub-CA-Zertifikat erfordern, damit sie ihre eigenen Zertifikate als Zertifizierungsstelle ausstellen können. Dies wirft sofort einige Sicherheitsbedenken auf, da die Ausstellung eines Sub-CA-Zertifikats für eine Man-in-the-Middle-Anwendung diese Anwendung praktisch zu einer ausstellenden CA macht. Sollte diese Anwendung kompromittiert werden, könnte das Sub-CA-Zertifikat möglicherweise verwendet werden, um vertrauenswürdige Zertifikate, signierte CRLs oder weitere Sub-CA-Zertifikate auszustellen.
In der Regel werden die CSRs mit zwei Hauptthemen ausgestellt:
- Keine Beschränkung der Pfadlänge
- Keine durchgesetzte Politik
Diese Anwendungen können jedoch zusätzliche Funktionen anfordern, die sie nicht haben sollten, wie z. B. Code Signing oder OCSP Signing.
Wenn ein Sub-CA-Zertifikat für diese Anwendungen benötigt wird, sollte es ein Mindestmaß an Funktionalität aufweisen.
Was ist die Alternative?
Normalerweise würden wir die CSR mit einer neuen policy.inf-Datei neu signieren, die die Microsoft Application Policy Constraints verwendet, um die Verwendung des Zertifikats einzuschränken. Dies funktioniert bei Microsoft-Zertifizierungsstellen, da Anwendungsrichtlinieneinschränkungen ein Microsoft-Standard sind, aber es ist nicht anwendbar für CA-Appliances, deren Anfragen nicht von Microsoft v2-Zertifikatsvorlagen stammen. Die Anwendungsrichtlinieneinschränkungen werden von der Proxy- oder SSL Intercept-Anwendung effektiv ignoriert.
Einschränkung der Zertifikatsnutzung
Um die SSL Intercept- oder Proxy-Anwendung daran zu hindern, Zertifikate mit einer Funktionalität auszustellen, die über das hinausgeht, was sie sollte, fügen wir der Anforderung eine Erweiterung für die erweiterte Schlüsselnutzung (Enhanced Key Usage) hinzu. Normalerweise geben Sub-CAs keine EKU an, und die Aufnahme eines neuen EKU-Abschnitts in die policy.inf bewirkt zweierlei:
- Nehmen Sie nur diese spezifischen EKUs in das Sub-CA-Zertifikat auf.
- Überschreiben Sie die angeforderten EKUs in der CSR.
Die CSR muss entweder von der Root-CA oder einer Policy-CA mit der command signiert werden:
- Certreq - Richtlinie "original_CSR.req" "Policy_file.inf" "new_request.req"
Die Policy_file.inf könnte zum Beispiel so aussehen:
[Version]
Signatur="$Windows NT$"
[Strings]
DefaultPolicyOID = "1.2.3.4.1455.67.89.5"
PolicyNotice = "Diese Zertifizierungsstelle ist eine private Web-Proxy-CA. Zertifikate, die von dieser Web-Proxy-CA ausgestellt werden, werden nicht verwaltet und sind möglicherweise nicht mit den Richtlinien konform. Weitere Informationen finden Sie unter: https://CDP.contoso.com/PKI/cps.txt"
PolicyURL = "https://CDP.contoso.com/PKI/cps.txt"
[PolicyStatementExtension]
Policies = Standardrichtlinie
[DefaultPolicy]
OID = %DefaultPolicyOID%
NOTICE="%PolicyNotice%"
URL="%PolicyURL%"
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1 ; Server-Authentifizierung
[Erweiterungen]
2.5.29.19 = "{text}ca=1&pathlength=0"
2.5.29.15 = AwIBBg==
Kritisch = 2.5.29.19,2.5.29.15
Dadurch wird eine CSR erstellt, die, wenn sie signiert ist, ein Zertifikat mit den angegebenen EKUs erzeugt. Sobald das Zertifikat auf der SSL Intercept- oder Proxy-Anwendung installiert ist, kann die Anwendung nur noch Zertifikate mit den in der EKU des Sub-CA-Zertifikats definierten Richtlinien ausstellen.
Zusammenfassung
Wenn Sie ein Sub-CA-Zertifikat für eine SSL Intercept- oder Proxy-Anwendung benötigen, sollten Sie in Erwägung ziehen, die CSR zurückzutreten, um eine Richtlinie, eine Pfadlängenbeschränkung und eine EKU-Beschränkung anzuwenden, um zu verhindern, dass die Anwendung Zertifikate mit Verwendungen generiert, die über das erforderliche Maß hinausgehen.
