Server 2008/2012: PKI installieren (Teil 1)

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:

image

Im Server Manager wird die Rolle „Active Directory -Zertifikatsdienste“ hinzugefügt

PKi

Als Rollendienst wird nur die Zertifizierungsstelle benötigt

image

Da es sich bei dem Server um kein Active Directory Mitglied handelt, kann nur „Eigenständig“ als Installationstyp gewählt werden

image

Da es sich um die Root-CA handelt, wird bei Zertifizierungsstellentyp „Stammzertifizierungsstelle“ ausgewählt

image

Und da wir keine Migration oder Recovery einer CA durchführen wollen, erstellen wir einen neuen privaten Schlüssel

image

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.

image

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…

image

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.

image

Den Rest der Dialoge mit „Weiter“ bestätigen. Sobald die Installation abgeschlossen ist, haben wir eine Root-CA.

image

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:

image

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)

13 Kommentare zu “Server 2008/2012: PKI installieren (Teil 1)”

  1. Hallo und guten Morgen,

    erst einmal vielen Dank für dieses Tutorial!!!

    Ich habe allerdings bereits am Anfang ein kleines Problem. Nach Eingabe der Zeilen in CMD:

    —————–
    net stop certsvc
    certutil -setreg CA\DSConfigDN „CN=Configuration,DC=savelkouls,DC=net“
    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“

    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://srv-web.savelkouls.net/cert/%%3%%8%%9.crl

    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://srv-web.savelkouls.net/cert/%%1_%%3%%4.crt

    net start certsvc
    ———

    steht in allen 4 Ordnern in der Zertifizierungsstelle unterhalb meiner CA:
    „Der RPC-Server ist nicht verfügbar. 0x800706ba (WIN32: 1722 RPC_S_SERVER-UNAVAILABLE….

    Könnten Sie mir einen Tip geben?
    DANKE!
    Gysbert

  2. Guten Abend
    herzlichen Dank für die tolle Anleitung!, ich habe eine etwas komische aber wohl einfache Frage:

    Im CAPolicy.inf könnte ja unter
    [CRLDistributionPoint]
    die CRL-Publizierung definiert werden.

    Warum wird die CRL-Publizierung erst mit dem Batchfile definiert?
    Gleiches gilt ja vermutlich auch z.B. für den Wert von ValidityPeriodUnits.

    Vielen Dank für jeden Tipp,
    mit lieben Grüssen,
    Thomas Schittli

  3. @Thomas

    Ich vermute mal das liegt daran, dass die CRL-Publizierung VOR der Installation der Zertifizierungsstelle keinen Sinn macht. Durch das Fehlen des Rollendienstes fehlt beispielsweise der Pfad „%WINDIR%\system32\CertSrv\CertEnroll“. Demnach kann dort auch nicht die CRL-Datei liegen, die ja logischerweise auch noch nicht existiert. Diese wird auch erst nach der Installation des Rollendienstes erstellt. Ich kann also die Sperrliste nicht veröffentlichen wenn sie noch nicht da ist.

    Die viel größere Frage ist jedoch warum ich erst in der CAPolicy.inf sage, dass es keine AIA und CDP gibt/geben soll damit Clients sie nicht überprüfen müssen, aber dann werden genau diese beiden mit der Konfiguration via oben genanntes Skript konfiguriert. Erst sage ich, es gibt sie nicht und dann gibts sie doch; das verstehe ich nicht so ganz. Bedeutet das, dass durch die CAPolicy.inf die Standardeinträge der CDP und AIA gelöscht und durch das Skript die angepassten Pfade/URL eingetragen werden?

    Andere Frage: Muss ich im Skript unbedingt diese %%-Parameter nutzen oder kann ich einfach zum Beispiel „RootCA.crl“ bzw. „RootCA.crt“ am Ende des Pfads/URL hinschreiben? Macht man das um nach außen hin das was hinter den Parametern steht zu verschleiern?

    Um eine Antwort würde ich mich freuen.

    Grüße
    Astraube

    1. @AStraube:

      Hi,

      Ich Vermutung ist korrekt. Zu Ihrer Frage: Bei dem AIA und CDP handelt es sich um die URLs, wo die Clients das Root-Zertifikat und die Root Sperrliste finden. Diese Infos sollten Sie ihren Clients mitgeben.

      Sie müssen nicht zwingend die Variablen nutzen, sie können die URLs auch hardcoded eintragen.

      Gruß,
      Frank

  4. Guten Abend Frank,

    danke für die Antwort. Den Zweck von CDP und AIA habe ich schon verstanden. Was ich wie gesagt nicht verstehe ist, dass am Anfang der Anleitung gesagt wird, dass die Clients keine Sperrliste oder AIA der RootCA prüfen müssen, da sie sowieso offline geht, danach aber trotzdem die beiden URLs eingetragen werden.
    Macht man das damit die Clients die RootCA-Sperrliste erreichen müssen falls die SubCA kompromittiert wird und daraufhin deren Zertifikat in die RootCA-Sperrliste eingetragen wird? Warum dann oben die beiden CDP und AIA Einträge in der CAPolicy.inf und deren Erklärung darunter? Wie bereits gefragt, was bewirken die beiden Befehle genau? Löschen sie nur die Standardeinträge aus CDP und AIA damit nur die Einträge aus dem späteren Konfigurationsskript drin stehen?
    Ich beginne das ganze Bild langsam zu verstehen, aber der Punkt ist für mich noch etwas widersprüchlich.
    Um Aufklärung würde ich mich freuen.

    Grüße
    AStraube

  5. Hallo,

    neben der letzten Frage hätte ich noch eine. Lassen sich die LDAP-Einträge aus CDP und AIA irgendwie im Zertifikat unkenntlich machen? Dort steht ja logischerweise im Klartext der Distinguished Name der CA inklusive Domänenname. Im Produktivbetrieb wäre das doch schlecht, wenn ein Zertifikat aus dem Firmennetz gelangt oder ein unverschlüsselter Laptop eines Außendienstlers gestohlen wird/abhanden kommt.

    Ist es möglich CDP und AIA so zu konfigurieren, dass im Zertifikat und in der Sperrliste ausschließlich die URL steht, welche ich angegeben habe damit Clients (im Außendienst, ohne Verbindung zur Domäne, auch kein VPN) auf die dort hinterlegte aktuelle Sperrliste zugreifen können?
    Oder muss ich für diese Clients eine zweite SubCA bauen oder gar aus der zweistufigen PKI eine dreistufige machen; also dass Außendienstler die Zertifikate der zweiten Stufe nutzen und Domänenbenutzer die der dritten?

    Grüße

  6. Guten Abend Astraube

    vielen Dank für die Antwort zur Frage CAPolicy.inf vs batch – ich habe die CRL-Publizierung nur als Beispiel genommen, die Frage stellt sich grundsätzlich:

    Was gehört in CAPolicy.inf?
    Was gehört in ein Script?
    … und warum.

    Die Argumentation, dass die CRL-Publiziereung nicht ins CAPolicy.inf File kommt, weil noch Dinge fehlen, könnte ja auch für RenewalKeyLength gelten: VOR der Installation ist dieser Wert nutzlos.

    Leider kenne ich die Antworten auf Deine etwa 3 offenen Fragen auch nicht… ich installiere jetzt mal unsere erste PKI und vielleicht finde ich dann noch eine Antwort…

    Liebe Grüsse, Tom

  7. Hallo Tom,

    danke für die Antwort. Hier meine erste Frage nochmal anders ausgedrückt.
    Also muss ich das Folgende gar nicht in die CAPolicy.inf der RootCA eintragen?

    [CRLDistributionPoint]
    Empty = true
    [AuthorityInformationAccess]
    Empty = true

    Wenn ich das eintrage und die Zertifizierungsstelle installiere, finde ich in den Einstellungen->Erweiterungen trotzdem die vier Standardeinträge im Sperrlisten-Verteilungspunkt (CDP) und Zugriff auf Stelleninformationen (AIA). Also „C:\Windows\…“ , LDAP-Pfad und die beiden Standard-URL. Insofern besteht die Frage was diese vier Zeilen in der CAPolicy.inf bewirken sollen wenn sie die Standardeinträge nicht entfernt.

    Und die Renewal-Variablen MÜSSEN in der CAPolicy.inf stehen, da es nachträglich keine Möglichkeiten gibt den Wert für die Gültigkeit des erneuerten Zertifizierungsstellenzertifikats zu ändern. Es gibt anders als bei den anderen Einstellungen keinen Registry-Eintrag dafür; jedenfalls konnte ich keinen finden. Läuft z.B. das Rootzertifikat dann in 20 Jahren ab, wenn ich das bei der Konfiguration nach der Installation der ADCS-Rolle so einstellt habe, und dieses wird dann erneuert, wird es nicht wieder um 20 Jahre erneuert sondern nur um zwei Jahre. Es sei dahingestellt, ob die RootCa in 20 Jahren noch existiert. :-)

    Im Technet-Artikel zur CAPolicy.inf-Datei stehen die Renewal-Sachen auch mit drin.
    https://technet.microsoft.com/de-de/library/jj125373.aspx

    Ebenso im MSDN-Artikel. Dort gibt es im Übrigen auch keine CDP- und AIA-Einträge.
    https://msdn.microsoft.com/de-de/library/cc728279%28v=ws.10%29.aspx
    Der Grund ist offenbar, dass ab Server 2008 diese Einträge nicht mehr notwendig sind, da Root-Zertifikate von deren Zertifizierungsstellen grundsätzlich keine CDP- und AIA-Informationen enthalten. Es ist also noch ein Relikt von Server 2003 und früher. Quelle:
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/f6145a29-812a-49f0-b290-0290907d7ec6/root-ca-capolicyinf?forum=winserversecurity

    Im Übrigen habe ich es bei mir nun gelöst mit der Unkenntlichmachung von Sperrlisten-Informationen in Zertifikaten. In CDP der Root und Sub stehen nur noch drei Einträge:
    – „C\Windows….“ (beide Haken gesetzt)
    – LDAP-Pfad (keine! Haken gesetzt)
    – meine über das Internet erreichbare URL zur jeweiligen Sperrlistendatei (alle 3 Haken gesetzt, reichen aber auch die ersten beiden)
    Bei AIA habe ich keine Haken aktiv (Standard-URLs habe ich entfernt), da ich es nicht nutzen will.
    Somit steht im SubCA-Zertifikat und in allen Zertifikaten, welche die Sub ausstellt ausschließlich die von mir gesetzte URL und stehen keine sicherheitskritischen Informationen drin. Nachteil: Clients müssen mit dem Internet verbunden sein, damit die drei Sperrlisten überprüft werden können, aber was ist heute schon nicht alles mit dem Internet verbunden? ;-)

    Grüße

    AStraube

  8. Hey,

    unter Windows Server 2003 mussten die Eintgäge:

    [AuthorityInformationAccess]
    Empty = true
    [CRLDistributionPoint]
    Empty = true

    mit in die CAPolicy.inf aufgenommen werden um zu verhindern das
    die AIA und CDP Erweiterungen in Stammzertifizierungsstellenzertifikat
    aufgenommen werden.
    Bei Windows Server 2008 / 2012 wird automatisch ein Stammzertifizierungsstellenzertifikat
    ohne AIA und CDP erstellt.

    Grüße
    Simon

  9. Hallo Frank,

    ich muss die CA noch einmal installieren!

    Ich laufe auch nach dem 3. Versuch bei Eingabe auf der Subca in nachstehenden Fehler:

    c:\certutil -dspublish -f meineRoot-CA.crl
    ldap:///CN=Root-CA,CN=SRV-Root,CN=CDP,CN=Public Key Services,CN=Services,DC=UnavailableConfigdN?certificationRevocationList?base?objectClass=cRLDistributionPoint?certificateRevocationList
    ldap: 0xa: 0000202B: RefErr: DSID-0310082F, data 0. 1 Access Points
    ref 1: ´unavailableconfigdn´
    CertUtil: -dsPublish-Befehl ist fehlgeschlagen: 0x8007202b
    Certutil: Eine Referenzauswertung wurde vom Server zurückgesendet.

    Der Befehl „CertUtil -dspublish -f SRV-Root_Root-CA.crt“
    war hingegen erfolgreich!
    Könntest Du mir einen Tip geben was ich falsch gemacht haben könnte?
    LG und Danke
    Gysbert

  10. Hallo Gysbert,

    denselben Fehler hatten Sie doch schoneinmal -> siehe Teil 2 der Anleitung -> Kommentare. Haben Sie das so gemacht wie in meinem Kommentar dort beschrieben? In der Zertifikatsstelle fehlt der „CA\DSConfigDN“- und „CA\DSDomainDN“-Eintrag oder einer von beiden ist falsch.

    Löschen Sie die Datei meineRoot-CA.crl auf SRV-Root in C:\Windows\System32\Certsrv\CertEnroll

    Führen Sie auf dem SRV-Root aus:
    certutil -setreg CA\DSConfigDN „CN=Configuration,DC=savelkouls,DC=net“
    certutil -setreg CA\DSDomainDN „DC=savelkouls,DC=net“
    net stop certsvc
    net start certsvc

    Kopieren Sie die neu erstellte Sperrliste im selben Verzeichnis auf Ihre Sub und veröffentlichen Sie diese erneut.

    Falls sich der Distinguished Name Ihrer Domäne geändert hat müssen Sie dies ggf. anpassen.

    Ich glaube um ein Zertifikat (.crt) zu veröffentlichen sind die Einträge nicht notwendig.

    Grüße

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.