Inhaltsverzeichnis
Letzte Aktualisierung am 21.07.2020, 14:07:58 Uhr
Zertifikate werden auch im Unternehmensnetzwerk immer wichtiger. Viele Services können inzwischen SSL/TLS umgehen. Voraussetzungen dafür ist, dass ein SSL-Zertifikat zur Verfügung gestellt wird. Im folgenden Artikel beschreibe ich die Installation einer internen, zweistufigen Zertifizierungsstelle mit Hilfe von Windows Server 2012R2. Je größer das Unternehmen ist, desto mehr Planung bezüglich Anforderung, Installation, Betrieb und Organisation wird erforderlich sein.
Ich möchte mit diesem Artikel einen kleinen Einblick in das Thema geben. Dies ersetzt in keinem Fall eine ordentliche Planung bezogen auf die jeweiligen Gegebenheiten der jeweiligen Umgebung!
Aufbau der Umgebung
Voraussetzungen
– Funktionstüchtige Active Directory-Domäne (in meinen Fall Windows Server 2012R2)
– VM mit Windows Server 2012R2, die nicht Mitglied in der Domäne ist (DNS-Name: pki01).
– VM mit Windows Server 2012R2, die Mitglied in der Domäne ist (DNS-Name: pki02).
– Der Servername und DNS-Suffix können nach der Installation der entsprechenden Rolle(n)nicht mehr verändert werden!
Installation der Stammzertifizierungsstelle
Diese VM (pki01) dient dazu um allen Unterzertifizierungsstellen (SubCA) ein Zertifikat auszustellen bzw. erneuern. Diese stellt später keinerlei Zertifikate für Webdienste, SIME o.ä. aus! Die VM wird nach der Ausstellung der Zertifikate und Sperrlisten heruntergefahren und gut versteckt. Somit ist eine Kompromittierung nicht ohne weiteres möglich. Des Weiteren wäre es später möglich, dass die Stammzertifizierungsstelle mit Hilfe von z.B. GlobalSigns Trusted Root zu validieren und somit sind alle ausgestellten Zertifikate der Unterzertifizierungsstelle auch im Internet ohne weiteres gültig.
Ersteinrichtung der Stammzertifizierungsstelle
Konfiguration der Stammzertifizierungsstelle
Parameter für die Sperrlistenveröffentlichung
Damit hat die Sperrliste der pki01 nach Veröffentlichung eine Gültigkeit von einem Jahr. Daher eine Erinnerung in den Kalender setzen, dass man nach 11 Monaten die Sperrliste erneuern muss. | |
Gültigkeitsdauer auszustellender Zertifikate
Die Gültigkeitsdauer eines Zertifikats ist standardmäßig ein Jahr. Das ist für Zertifikate bezogen auf Zwischenzertifizierungsstelle (SubCA) deutlich zu kurz. Die Laufzeit darf aus meiner Sicht ruhig 10 Jahre betragen. Erfolgt eine Kompromittierung der SubCA wird einfach eine Neue aufgesetzt und das Zertifikat in der Stammzertifizierungsstelle gesperrt. Ansonsten gilt hier meine Erläuterung von Bild 20 (Laufzeit des Zertifikats).
[…] Installation einer zweistufigen PKI unter Windows Server (Teil 1) […]
hallo
ich versuche mit deiner beschreibung das ganze mit server 2019 einzurichten,
ich bekomme aber leider beim teil 2 beim abschnitt: zwischenzertifizierungstelle aktivieren, unter „zertifizierungsstellenzertifikat installieren“
die Meldung:
Die Zertifizierungskette kann nicht überprüft werden, Möchten Sie den Fehler ignorieren und den Vorgang fortsetzen?……….. da der Sperrserver offline war 0x80092013……..
ich habe die Fehlermeldung abgekürzt.
was habe ich falsch gemacht ,
Danke
Ich hatte einen ähnlichen Fehler. Hatte vergessen, nach dem kopieren der Sperrliste auf die SUBCA den CName Eintrag im DNS zu setzen. Wenn man hier den ALIAS PKI (wie beschrieben) wählt und auf die SUBCA verweist findet er auch seine Sperrliste.
Hi, ich habe denselben Fehler. Bei mir allerdings das Phänomen, dass der CNAME-Eintrag da ist und auf die SubCA verweist. Server können miteinander kommunizieren (das ist sichergestellt). Daher die Frage: das wird mir ohnehin nicht ganz klar aus den Screenshots – muss die CRL also für die Installation des RootCA-Zertifikats auf der SubCA über die http-Adresse abrufbar sein? Die URL läuft bei mir nämlich auf diesen Fehler vom IIS: 404 – File or directory not found.The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable. Ich bitte um Hilfe (ich will nicht… Weiterlesen »
Hallo Leon,
die SubCA agiert der einfacher Halber auch als Distribution Point. Die URL der CRL Sperrliste zeigt aus diesem Grund auf die SubCA. Das bedingt natürlich, dass die notwendigen Dateien der RootCA auf der SubCA im entsprechenden Verzeichnis liegen müssen.
Gruß,
Daniel
Hi, danke für die flotte Antwort 🙂 ich konnte das Problem lösen, da ich offensichtlich nicht ganz aufmerksam war und die .crl- und.crt-Dateien aus dem Verzeichnis, auf das die URL zugegriffen hat, entfernt habe. Einfach wieder dort ablegen hat dann natürlich Wunder gewirkt.
Freundlichen Gruß
[…] Hier können die exakte Schritte aus Teil 1 wiederholt werden. […]
Hallo Daniel
Erstmals herzlichen Dank für diesen ausführlichen Blog. Er hat mir bei meiner Einrichtung sehr geholfen.
Was ich jedoch vermisse, ist der Eintrag zur Domain in der Root CA:
certutil -setreg CA\DSConfigDN „CN=Configuration,DC=domain,DC=local“
certutil -setreg CA\DSDomainDN „DC=domain,DC=local“
Anschliessend hat bei mir alles gefunzt
Liebe Grüsse
Dani
Hallo Dani,
vielen Dank für den Hinweis. Möchtest du kurz die beiden Befehle erläutern und was davor bzw. danach funktioniert hat? Ich kann dir nämlich nicht ganz folgen.
Gruß,
Daniel
Hallo,
ich habe eine Verständnisfrage.
Oben steht, dass der Server SUB-CA „pki02“ hieße. Weiter unten steht: „Bei der neuen Adresse habe ich absichtlich pki statt pki01 angegeben. Es handelt sich dabei um einen Eintrag im DNS-Server vom Typ CNAME“
Jetzt habe ich die Sub ebenfalls „pki02“ genannt…und im DNS bekomme ich natürlich die Fehlermeldung. Denn ich verweise ja auf „PKI02.XXXXXXXXXX.local“…und das kann ja nicht klappen.
Was habe ich hier falsch verstanden?
DANKE:-)
Hallo,
der CNAME im DNS-Server muss auf den Servernamen, auf dem du die SubCA02 installiert hast, zeigen. Sonst funktioniert der Alias natürlich nicht.
Grüße