Konfigurieren einer Secure Socket Layer (SSL) Zertifikatvorlage für Web Server
Nachfolgend eine Anleitung für die Konfiguration einer Webserver-Vorlage mit empfohlenen Einstellungen.
Für diesen Schritt sind Enterprise Administrator- oder entsprechend delegierte Rechte für die Erstellung und Bearbeitung von Zertifikatvorlagen notwendig.
Konfiguration der Zertifikatvorlage
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.
Die Konfiguration der Zertifikatvorlage wird über die Zertifikatvorlagen-Managementkonsole (certtmpl.msc) vorgenommen.
Als Ausgangsbasis wird die Standard-Zertifikatvorlage "Web Server" verwendet und eine Kopie davon erstellt.
Karteikarte "Compatibility"
Wir beabsichtigen, Key Storage Provider (KSP) einzusetzen. Hierfür ist es erforderlich, die Kompatibilitätseinstellungen für Zertifizierungsstelle und Zertifikatempfänger auf "Windows Vista" bzw. "Windows Server 2008" zu setzen.
Karteikarte "General"
In der Karteikarte "General" wird ein aussagekräftiger Name verwendet. Die Zertifikatgültigkeit sollte nicht höher als zwei Jahre betragen.
Apple erzwingt mittlerweile , dass Webserver-Zertifikate nicht länger als zwei Jahre (825 Tage) gültig sind.
Chrome und Safari limitieren die Zertifikatgültigkeit mittlerweile sogar auf nur ein Jahr (398 Tage), jedoch werden interne Zertifizierungsstellen von dieser Einschränkung explizit ausgeschlossen.
Die "Renewal Period" ist nicht von Belang, da bei dieser Form von Zertifikatvorlage keine automatische Erneuerung möglich ist.
Karteikarte "Request Handling"
In der Karteikarte "Request Handling" muss der Purpose an den zu verwendenden Schlüsselalgorithmus angepasst werden. Hintergrund ist, dass je nach Schlüsseltyp unterschiedliche Anforderungen an die "Key Usage" Erweiterung des Zertifikats gestellt werden (Siehe RFC 5246 und RFC 4492 ).
| Schlüsselalgorithmus | Wert |
|---|---|
| RSA | Signature and Encryption |
| ECDSA | Signature |
| ECDH | Signature and Encryption |
Karteikarte "Cryptography"
In der Karteikarte "Cryptography" muss nun die Kategorie "Key Storage Provider" gewählt werden und der jeweilige Schlüsselalgorithmus.
Als Provider sollte der Microsoft Software Key Storage Provider ausgewählt werden, wenn nicht beabsichtigt ist, die Schlüssel beispielsweise mit einem Trusted Platform Modul (TPM) zu schützen.
Wenn ein Cryptographic Service Provider (CSP) verwendet werden soll, sollte der "Microsoft RSA SChannel Cryptographic Provider " verwendet werden. Dieser unterstützt nur AT_KEYEXCHANGE, daher muss in der Karteikarte "Request Handling" der Purpose auf "Signature and Encryption" eingestellt werden. Grundsätzlich sollte nach Möglichkeit einem Key Storage Provider der Vorzug gegeben werden.
Die Wahl des Providers hat nur für Zertifikatbeantragungen, die die Zertifikatvorlage bei der Beantragung auslesen (also manuelle oder automatische Zertifikatbeantragungen per Autoenrollment) Auswirkungen.
Karteikarte "Subject Name"
In der Karteikarte "Subject Name" wird darauf geachtet, dass die Option "Supply in the request" ausgewählt ist (Standardeinstellung). Diese bewirkt, dass der Antragsteller die Identität im Zertifikat bestimmen kann. Dies ist notwendig, da für Webseiten oft ein Alias verwendet wird, welcher nicht als Kerberos-Identität abgebildet werden kann. Entsprechend unterscheiden sich die Identität des Antragstellers und die der Webseite voneinander.
Da die vorige Einstellung ein Sicherheitsrisiko birgt (der Antragsteller könnte Zertifikate für beliebige Subject Names beantragen), muss zwingend im Karteireiter "Issuance Requirements" die Option "CA certificate manager approval" gesetzt sein. Sie bewirkt, dass die Zertifikatanforderung nicht direkt ausgestellt wird, sondern stattdessen im Ordner "Pending Requests" landet, wo sie ein Zertifikatmanager überprüfen kann .
Sollte man den Haken für "CA certificate manager approval" entfernen, erscheint auch eine entsprechende Warnung.
Karteikarte "Security"
In der Karteikarte "Security" kann nun der gewünschten Person oder Benutzergruppe das "Enroll"-Recht erteilt werden.
Da die Zertifikatvorlage so konfiguriert ist, dass eingehende Zertifikatanforderungen im Ordner "Pending Requests" landen und erst durch einen Zertifikatmanager überprüft und freigegeben werden müssen, ist die Vergabe des "Enroll"-Rechts wie hier im Beispiel kein Sicherheitsrisiko.
Weitere Sicherheitshärtung
Eine Einschränkung des beantragbaren Zertifikatinhalts (beispielsweise, welche Domänennamen beantragt werden können) und die Sicherstellung, dass der korrekte Schlüsselalgorithmus verwendet wird, kann mit dem TameMyCerts Policy Modul für die Zertifizierungsstelle gewährleistet werden.
Beantragen eines Webserver-Zertifikats
Die Vorgehensweise zur Beantragung ist im Artikel "Manuelle Beantragung eines Webserver-Zertifikats " beschrieben.
Externe Quellen
- Enforce 398-day validity for certificates issued on-or-after 2020-09-01 (Chromium Projekt)
- About upcoming limits on trusted certificates (Apple)
- Requirements for trusted certificates in iOS 13 and macOS 10.15 (Apple)
- Reducing TLS Certificate Lifespans to 398 Days (Mozilla)
- Limit TLS Certificates to 398 day validity after Aug 31, 2020 (Mozilla)