PKI Konzept: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „1 PKI Konzept / Umsetzung 1.1 Ziel-Zustand Nach Best-Practice von Microsoft wir die PKI als 2-stufige PKI installiert. Das bedeutet, es gibt eine Root-CA die…“ |
Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
1 PKI Konzept / Umsetzung | 1 PKI Konzept / Umsetzung | ||
1.1 Ziel-Zustand | 1.1 Ziel-Zustand | ||
| Zeile 8: | Zeile 7: | ||
Der Root-CA Server wird offline gehalten, wird kein Mitglied der Domäne werden und bekommt ein eigenes lokales Administrator Passwort. | Der Root-CA Server wird offline gehalten, wird kein Mitglied der Domäne werden und bekommt ein eigenes lokales Administrator Passwort. | ||
Im Idealfall wird der Server exportiert und außerhalb der Fabric aufbewahrt. | Im Idealfall wird der Server exportiert und außerhalb der Fabric aufbewahrt. | ||
Mit der 2-stufigen PKI soll sichergestellt werden, dass falls | Mit der 2-stufigen PKI soll sichergestellt werden, dass falls die Sub-CA kompromittiert wurde, das Zertifikat entzogen werden kann und Clients dem Sub-CA Zertifikat nicht mehr vertrauen. Durch das offline halten, ist sichergestellt, dass niemand die Root-CA kompromittieren kann. | ||
Denkbar ist außerdem, in Kundendomänen eigene Sub-CAs zu installieren, die ebenfalls ein Zertifikat von der Root-CA bekommen | Denkbar ist außerdem, in Kundendomänen eigene Sub-CAs zu installieren, die ebenfalls ein Zertifikat von der Root-CA bekommen | ||
Aktuelle Version vom 20. Januar 2016, 13:15 Uhr
1 PKI Konzept / Umsetzung
1.1 Ziel-Zustand Nach Best-Practice von Microsoft wir die PKI als 2-stufige PKI installiert. Das bedeutet, es gibt eine Root-CA die offline gehalten wird und die nur Zertifikate für die Untergeordneten CAs ausstellen wird und es wir eine untergeordnete (Sub-CA) geben, die für das Ausstellen von Zertifikaten für Computer und Dienste zuständig ist.
Der Root-CA Server wird offline gehalten, wird kein Mitglied der Domäne werden und bekommt ein eigenes lokales Administrator Passwort. Im Idealfall wird der Server exportiert und außerhalb der Fabric aufbewahrt. Mit der 2-stufigen PKI soll sichergestellt werden, dass falls die Sub-CA kompromittiert wurde, das Zertifikat entzogen werden kann und Clients dem Sub-CA Zertifikat nicht mehr vertrauen. Durch das offline halten, ist sichergestellt, dass niemand die Root-CA kompromittieren kann.
Denkbar ist außerdem, in Kundendomänen eigene Sub-CAs zu installieren, die ebenfalls ein Zertifikat von der Root-CA bekommen
1.2 Umsetzung Das Zertifikat der Roo-CA wird 20 Jahre gültig sein, ausgestellte Sub-CA Zertifikaten bekommen eine Gültigkeit von 10 Jahren
1.2.1 Installation Root-CA Der Server für die Root-CA wird kein Domänen-Mitglied und das lokale Administrator Passwort unterscheidet sich von dem üblichen VM-Fabric lokalen Administrator Passwort
Installation Windows Updates Installation Serverrolle Active Directory-Zertifikatsdienste -> Zertifizierungsstelle Konfiguration der CA als Eigenständige Zertifizierungsstelle und als Stammzertifizierungsstelle Neuen Privaten Schlüssel erstellen Kryptografie SHA256 mit Schlüssellänge 4096 Name der Zertifizierungsstelle vertical-fabric-RootCA Der Gültigkeits-Zeitraum von 10 Jahren für die SubCA Zertifikate wird mit den folgenden Befehlen festgelegt certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"
Konfiguration der Zertifikatssperrlisten
die Zertifikatssperrlisten der Root-CA müssen von Clients erreichbar sein, auch wenn die Root-CA offline ist. Dazu werden diese auf einem extra Server abgelegt in unserem Fall der Sub-CA Server
Damit die Zertifikatssperrlisten nicht regelmäßig aktualisiert werden müssen, wird das Erneuerungsinterval auf 2 Jahre gesetzt
Dazu mit Recht auf Gesperrte Zertifikate klicken und die Eigenschaften aufrufen. Darin dann das Intervall auf 2 Jahre erhöhen
In der Commandline folgende Befehle ausführen
certutil -setreg ca\DSConfigDN "CN=Configuration,DC=vertical,DC=root“ certutil -setreg ca\DSDomainDN “DC=vertical,DC=root”
Über den Servermanager die Zertifizierungsstellen-Verwaltung aufrufen Eigenschaften der Zertifizierungsstelle öffnen (Rechtsklick auf vertical-fabric-RootCA) Register Erweiterte Einstellungen „C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
Sperrlisten an diesem Ort veröffentlichen Deltasperrlisten an diesem Ort veröffentlichen
LDAP Eintrag: folgende Optionen auswählen
In alle Sperrlisten einbeziehen In CDP-Erweiterung des ausgestellten Zertifikates einbeziehen
http://vf-v0040.vertical.root/CertEntroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
(BestPractice ist eigentlich als URL nicht den Computernamen zu verwenden, sondern einen CNAME. Z.B. ca.vertical.root) Die URL zeigt auf den IssueCA Server In Sperrlisten einbeziehen. Wird z. Suche von Deltasperrlisten verwendet CDP-Erweiterung des ausgestellten Zertifikats einbeziehen
Dienste neustarten. Dazu Rechtsklick auf CA, Alle Aufgaben und Dienst anhalten und Dienst starten ausführen Um die Zertifikatssperrlisten zu veröffentlichen, in der Zertifkatsstellen-Verwaltung mit Rechts auf „gesperrte Zertifikate“ klicken, „Alle Aufgaben“, „Veröffentlichen“ Die Sperrliste liegt unter „C:\Windows\System32\CertSrv\CertEnroll“ Die Sperrliste nun auf den IssueCA Server kopieren, ebenfalls nach „C:\Windows\System32\CertSrv\CertEnroll“ Beim Ersten Mal auch das Root-Zertifikat von „C:\Windows\System32\CertSrv\CertEnroll“ auf den IssueCA Server kopieren Veröffentlicht werden das Root-Zertifikat und die Sperrliste wie folgt certutil -dspublish -f OfflineCA_vertical-fabric-RootCA.crt RootCA certutil –dspublish -f vertical-fabric-RootCA.crl
1.2.2 Installation SubCA
Installation Windows Updates Installation Serverrolle Active Directory-Zertifikatsdienste -> Zertifizierungsstelle und Zertifizierungsstellen-Webregistrierung Konfiguration der CA als Unternehmenszertifizierungsstelle und als Untergeordnete Zertifizierungsstelle Neuen Privaten Schlüssel erstellen Kryptografie SHA256 mit Schlüssellänge 4096 Name der Zertifizierungsstelle vertical-fabric-SubCA Bei der Installation der SubCA wird ein Cert-Request erstellt. Das muss in einer Datei gespeichert werden. Mit dem Cert-Request wird auf der RootCA eine neue Anforderung eingereicht Die Anforderung landet dann unter Austehende Anforderungen hier kann das Zertifikat genehmigt und exportiert werden Auf der SubCA in der Zertifikatsverwaltung mittels Rechtsklick auf die CA, Alle Aufgaben installiert werden Konfiguration der Zertifikatssperrlisten Über den Servermanager die Zertifizierungsstellen-Verwaltung aufrufen Eigenschaften der Zertifizierungsstelle öffnen (Rechtsklick auf vertical-fabric-SubCA) Register Erweiterte Einstellungen „C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
Sperrlisten an diesem Ort veröffentlichen Deltasperrlisten an diesem Ort veröffentlichen
LDAP Eintrag: folgende Optionen auswählen
Alle Optionen auswählen, außer „In die IDP-Erweiterung ausgestellter CRLs einbeziehen“
http://vf-v0040.vertical.root/CertEntroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
(BestPractice ist eigentlich als URL nicht den Computernamen zu verwenden, sondern einen CNAME. Z.B. ca.vertical.root) Die URL zeigt auf den IssueCA Server In Sperrlisten einbeziehen. Wird z. Suche von Deltasperrlisten verwendet CDP-Erweiterung des ausgestellten Zertifikats einbeziehen
Dienste neustarten. Dazu Rechtsklick auf CA, Alle Aufgaben und Dienst anhalten und Dienst starten ausführen Konfiguration Webserver Zertifikatsvorlage zur Anzeige in der CA-Webregistrierung MMC aufrufen und das Snap-In Zertifkatvorlagen hinzufügen In den Eigenschaften der Webserver-Vorlage im Register Sicherheit die Gruppe Domänen-Benutzer hinzufügen und Registrieren erlauben
Meines Wissens wird bei Installation der Zertifizierungsstellen-Webregistrierung auch der IIS für die Zertifikatssperrlisten konfiguriert, also das virtuelle Verzeichnis „CertEnroll“ hinzugefügt mit Verweis auf den Ordner „C:\Windows\System32\CertSrv\CertEnroll“ Die aktuelle Konfiguration der SubCA weicht davon ab. Stattdessen wurde unter C:\inetpub der Ordner „CertEnroll“ händisch angelegt und im IIS das virtuelle Verzeichnis auf diesen Pfad umgebogen. In dem Ordner befinden sich die Zertifikatssperrlisten der RootCA und SubCA, das öffentliche RootCA und SubCA Zertifikat Das bedeutet, dass bei Aktualisierung der Zertifikatssperrlisten oder der Zertifikate diese in diesem Ordner (zusätzlich) abgelegt werden müssen
2 Ausstellen von Webserver Zertifikaten 2.1 Eine Zertifikatsanforderung (CSR) erstellen 2.1.1 Mittels IIS
Im IIS auf die oberste Ebene (Servername) klicken und Serverzertifikate öffnen Rechts auf Zertifikatsanforderung erstellen klicken Felder ausfüllen (Gemeinsamer Name ist der Name des Webservers z.B. www.vertical.de) Kryptografiediensteanbieter „Microsoft RSA SChannel…“ auswählen Bitlänge 2048 Die Anforderung kann dann gespeichert und mittels CA-Webregistrierung das Zertifikat erstellt werden
2.2 Ein Zertifikat mittels Zertifikatsanforderung (CSR) ausstellen
Im Browser die CA-Webregistrierung aufrufen: https://vf-v0040.vertical.root/certsrv Auf „oder senden Sie eine erweiterte Zertifikatanforderung ein.“ Klicken Reichen Sie eine Zertifikatanforderung ein, ... Den Inhalt der Anforderung in das „Gespeicherte Anforderung:“ Feld einfügen Zertifikatvorlage „Webserver“ auswählen und „Einsenden“ klicken Das Zertifikat kann im Anschluss heruntergeladen werden?
3 Erneuern der RootCA Zertifikatssperrliste zum 20.01.2018
Fabric-Server „OfflineCA“ hochfahren. Prüfung Datum der Zertifikatssperrliste in „C:\Windows\System32\CertSrv\CertEnroll“
Wenn nicht aktuell:
Zertifizierungsstellen-Verwaltung öffnen Rechtsklick auf „gesperrte Zertifikate“, „Alle Aufgaben“, „Veröffentlichen“ Datei vertical-fabric-RootCA.crl auf SubCA Server kopieren in folgende Verzeichnisse C:\inetpub\CertEnroll C:\Windows\System32\CertSrv\CertEnroll Zertifikat in Active Directory veröffentlichen certutil –dspublish -f vertical-fabric-RootCA.crl