Eine Zertifizierungsstelle ist unter Windows Server schnell installiert. Im wesentlichen wird die Rolle „Zertifizierungsstelle“ hinzugefügt, ein paar mal auf „Weiter“ geklickt und schon hat man eine CA die alle möglichen Zertifikate ausstellen kann. Somit hat man eine PKI, Funktioniert zwar, ist aber schlecht.
Eine PKI und deren CAs müssen gut geplant werden, dabei gilt es rechtliche, organisatorische und administrative Dinge zu berücksichtigen. Mal eben schnell eine CA installieren und Zertifikate für alle möglichen Zwecke auszustellen, ohne sich vorher Gedanken über Sperrlisten, Sicherheit und Anforderungen gemacht zu haben kann schnell fatal enden. Insbesondere wenn es um Themen wie Smartcard Authentifizierung oder Verschlüsselung (Bitlocker, EFS, S/MIME) geht.
Natürlich kann ich niemanden die sorgfältige Planung und Installation einer PKI abnehmen, aber dieses Howto liefert zumindest eine solide Basis für eine PKI, die vielen Anforderungen gerecht werden kann. Besser als die „Weiter…Weiter…Weiter..Fertigstellen“-Methode ist es allemal.
In diesem Howto wird eine 2-Stufige PKI, bestehend auf Offline Standalone CA und Active Directory integrierter Sub-CA (Unternehemens-CA) installiert. Dieses Howto enthält ebenfalls ein paar Anpassungen um die Sicherheit zu erhöhen und Probleme zu vermeiden.
Root CA
Dieses Howto dreht sich um eine 2-Stufige PKI, daher muss zunächst die Root-CA (oder auch Stammzertifizierungsstelle) installiert und konfiguriert werden. Dazu wird ein Windows Server 2008 (R2) oder Windows Server 2012 (R2) benötigt, die Standard Edition ist völlig ausreichend. In produktiven Umgebungen bietet sich eine VM an, da die Root-CA nur selten benötigt wird. Normalerweise ist die Root-CA offline, abgeschaltet, im Tresor eingeschlossen und verbuddelt. Eine VM bietet sich also an, dann kann der Tresor und das Loch etwas kleiner sein.
Für die Installation reicht ein Windows Server 2008 Standard oder Windows Server 2012 Standard. Ich habe einen Server 2008 R2 installiert, die Konfiguration ist bei Server 2012 aber identisch. Der Server ist kein Active-Directory Mitglied, nur alle Updates sind bisher installiert..
Bevor die Root-CA installiert wird, muss die CAPolicy.inf Datei erstellt werden. Ich verwende eine CAPolicy.inf mit folgendem Inhalt:
[Version] Signature = "$Windows NT$" [CRLDistributionPoint] Empty = true [AuthorityInformationAccess] Empty = true [certsrv_server] RenewalKeyLength = 4096 RenewalValidityPeriodUnits = 20 RenewalValidityPeriod = years
Die INF-Datei legt fest, dass die CA über keine AIA und CDP verfügt. Diese Angaben sind wichtig, da es sich um eine Offline-Root-CA handelt. Clients müssen also keine Sperrliste oder AIA der Root-CA prüfen. Weiterhin wird die Schlüsselverwendung eingeschränkt, damit die Root-CA nur Sub-CAs signieren kann. Die Root-CA soll ja schließlich keine Zertifikate für andere Verwendungszwecke ausstellen. Wenn man auch schon mal dabei ist, kann man auch gleich die Einstellungen für die Erneuerung des Root-Zertifikats vornehmen. Sollte das Zertifikat einmal erneuert werden, wird es ohne diese Einstellungen nur um 2 Jahre verlängert. Das würde auch bedeuten das keine Zertifikate mehr ausgestellt werden können, die eine längere Laufzeit als 2 Jahre haben.
Es muss also eine Datei mit dem Namen „CAPolicy.inf“ erstellt werden, die den oben gezeigten Inhalt enthält. Die CAPolicy.inf muss dann in das Windows Verzeichnis (C:\Windows) kopiert werden. Die CAPolicy.inf wird bei der Installation der Zertifizierungsstelle eingelesen, nachträglich funktioniert das nicht mehr.
Sobald die CAPolicy.inf im Windows Verzeichnis liegt, kann die CA installiert werden:
Im Server Manager wird die Rolle „Active Directory -Zertifikatsdienste“ hinzugefügt
Als Rollendienst wird nur die Zertifizierungsstelle benötigt
Da es sich bei dem Server um kein Active Directory Mitglied handelt, kann nur „Eigenständig“ als Installationstyp gewählt werden
Da es sich um die Root-CA handelt, wird bei Zertifizierungsstellentyp „Stammzertifizierungsstelle“ ausgewählt
Und da wir keine Migration oder Recovery einer CA durchführen wollen, erstellen wir einen neuen privaten Schlüssel
Der Reiter Kryptografie ist ein wichtiger Punkt, SHA1 gilt als geknackt und wird zukünftig auch nicht mehr von Microsoft als Hashalgorithmus unterstützt. Um für die nächsten Jahre auf der sichern Seite zu sein, wird hier SHA256 und 4096 Bit als Schlüssellänge ausgewählt. 2048 Bit Schlüssel gelten mittlerweile als Minimum.
Jetzt noch einen sprechenden Namen für die CA vergeben. Der Hostname des Servers sollte nicht Bestandteil des CA-Namens sein, es muss ja schließlich niemand den Hostnamen unserer Root-CA wissen…
Und nun zur abschließenden Frage: Wie lange soll die CA gültig sein? Nicht zu kurz und nicht zu lang, umso kürzer umso sicherer umso mehr Aufwand. Umso länger umso unsicherer umso weniger Aufwand. 5 Jahre würde ich als Minimum ansetzen, 20 Jahre als oberstes Maximum.
Den Rest der Dialoge mit „Weiter“ bestätigen. Sobald die Installation abgeschlossen ist, haben wir eine Root-CA.
Die CA kann nun bequem der Kommandozeile konfiguriert werden (Achtung: Anpassungen nötig, siehe unten):
net stop certsvc certutil -setreg CA\DSConfigDN "CN=Configuration,DC=frankysweb,DC=local" certutil -setreg CA\ValidityPeriodUnits 10 certutil -setreg CA\ValidityPeriod "years" certutil -setreg CA\AuditFilter 127 certutil -setreg CA\CRLPeriodUnits 1 certutil -setreg CA\CRLPeriod "years" certutil -setreg CA\CRLDeltaPeriodUnits 0 certutil -setreg CA\CRLDeltaPeriod "days" ::CRL-Publizierung, %%10 bedeutet, dass es sich bei dem Objekt um ein CRL-Publication-Point handelt certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://ca.frankysweb.de/cert/%%3%%8%%9.crl" ::AIA-Extension-URLs, %%11 bedeutet, dass es sich bei dem Objekt um einen AIA-Objekt handelt. certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:LDAP:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://ca.frankysweb.de/cert/%%1_%%3%%4.crt" net start certsvc
Die Befehle oben können in eine .BAT Datei kopiert werden und müssen dann etwas angepasst werden:
Zeile 3: Hier muss die Active Directory Konfigurationspartition angegeben werden. Meine AD-Domain heißt frankysweb.local. Daher ist es bei mir „CN=Configuration,DC=frankysweb,DC=local“. Der entsprechende Eintrag lässt sich per ADSI-Edit von einem Domain Controller ermitteln:
Zeile 17 und Zeile 20: Wenn sichergestellt werden soll, dass die Sperrliste auch von externen Clients erreichbar sein soll (Wichtig bei Clients ohne Verbindung zum AD), muss am Ende der Zeile einen Webserver angeben, der aus dem Internet erreichbar ist. Wer nur AD-Mitglieder bedienen muss, kann das Ende der Zeile entfernen (Nicht die ganze Zeile, nur das ab „n2“). Ich empfehle allerdings eine gültige URL einzutragen, später dazu mehr.
Abschließend müssen die Sperrliste und das Root-CA Zertifikat auf den Server kopiert werden der später Sub-CA werden soll. Ich kopiere also die Dateien aus „C:\Windows\System32\CertSrv\CertEnroll“ auf einen Server der ActiveDirectory Mitglied ist. Die Zertifikate müssen dort importiert werden (Teil 2)
So, nun haben wir eine Root-CA. Als nächstes ist die Active Directory integrierte CA (Sub-CA) an der Reihe (Teil 2)