Installation einer zweistufigen PKI (two tier pki)

das folgende Beispiel zeigt das Setup für eine interne zweistufige Zertifizierungsstelle. Die erste Stufe ist eine CA (Certification Authority) auf einem Server, der nicht Mitglied der Domäne ist. Dieser Server (Root CA) stellt lediglich ein Zertifikat für eine untergeordnete Instanz aus, und hat damit auch die Möglichkeit diese zu sperren. Die Root CA ist aus Sicherheitsgründen ausgeschalten, und wird nur zum Verlängern der Sperrliste eingeschalten. Die untergeordnete Instanz (Enterprise CA) ist ein Server, der Mitglied der Domäne ist. Dieser stellt die Zertifikate für die Clients aus, und nimmt die Requests entgegen.

Das Setup sieht die Verteilung der Zertifikate und Sperrlisten (Root- und Enterprise CA) an zwei Punkten vor. Der erste ist ein Webserver, der auch von nicht Domänen Clients kontaktiert werden kann. Voraussetzung ist eine funktionierende Namensauflösung sowie Zugriff mit dem HTTP Protokoll. Der Webserver wird mit einem im DNS System definierten CNAME angesprochen. Das bietet die Möglichkeit, den Webserver unkompliziert auszutauschen oder mit einem Loadbalancer für Redundanz auszustatten. Der zweite Verteilungspunkt ist das Active Directory. Der Zugriff erfolgt von Domänen Clients bevorzugt an diesem Punkt mit dem LDAP Protokoll. Beim Einsatz mehrerer Domain Controller ist der Zugriff hochverfügbar.

In Aussenstellen werden die Clients durch die AD Site-Awareness die angefragten Informationen vom lokalen Domain Controller erhalten. Die Zertifikatsprüfung ist dann für Domain Clients schneller, und auch bei Ausfall der Leitung zur Zentrale möglich. Der Webserver ist in der Regel nur über die Zentrale erreichbar.

 

Vorbereitungen

folgende Server sind neben einer vorhandenen Active Directory Domäne notwendig

• Offline Root CA (Windows Server)
• Enterprise CA (beim Einsatz von 2003/2008/R2 beachten: Standard hat gegenüber Enterprise eingeschränkte Zertifikatsvorlagen)
• Webserver (IIS oder Apache)

IIS Webserver

Installation der IIS Web Services mit der Powershell

Install-WindowsFeature -Name Web-Server -IncludeManagementTools

unter C:\inetpub wird ein Ordner CertEnroll erstellt. NTFS Vererbung deaktivieren, Domänen Gruppe Cert Publisher (bzw. bei detuschem System Zertifikatsherausgeber) hinzufügen, mit dem NTFS Recht Ändern. Ordner freigeben als CertEnroll, Jeder mit der Freigabeberechtigung Vollzugriff.

Die IIS Verwaltungs Konsole starten, Rechtsklick auf die Default Web Site, neues virtuelles Verzeichnis hinzufügen

Alias –> Certenroll
Physischer Pfad –> C:\inetpub\CertEnroll

Zum einfacheren Handling wird das Browsing der Website aktiviert, dazu navigiert man auf die Optionsseite des virtuellen Verzeichnisses –> Verzeichnis durchsuchen –> aktivieren

Enable IIS Double Escaping

damit später das Abrufen von Deltasperrlisten (Sperrlisten mit dem + am Ende) über den IIS möglich ist, muss eine Schutzfunktion deaktiviert werden.
Link zum Artikel URL_DOUBLE_ESCAPED; http://support.microsoft.com/kb/942076

1. Öffnen einer CMD auf dem IIS Webserver
2. cd %windir%\system32\inetsrv\
3. Appcmd set config „Default Web Site“ /section:system.webServer/Security/requestFiltering -allowDoubleEscaping:True
4. iisreset (neustart IIS)

DNS CNAME

Der Webserver wird später mit einer http Adresse in der Root- sowie Enterprise- CA konfiguriert. Dabei wird der Ablageort der Stelleninformationen fest in den ausgestellten Zertifikaten verdrahtet. Eine Änderung würde eine umkonfiguration der CAs bedeuten, sowie ein erneutes Ausstellen, Verteilen und Einbinden sämtlicher Zertifikate, die die geänderten Informationen beinhalten.

In der DNS Management Console, wird für die Zone der Domain ein Alias erstellt, z.B. PKI, der auf den A- Record des Webservers zeigt. Der Alias hat den Vorteil, dass das Ziel jederzeit umgelegt werden kann

 

Root CA, Standalone

1. CAPolicy.inf

Die CAPolicy.inf ist die Konfigurationsdatei, und wird bei der Installation der Active Directory Zertifikatsdienste (AD CS), sowie bei der Erneuerung des CA Zertifikats eingelesen. Der Name Active Directory ist hier etwas ungünstig gewählt. Diese Rolle wird nicht nur für die Domain integrierte (Enterprise), sondern auch für Standalone CAs installiert. Für eine Grundinstalltion der Zertifizierungsstelle ist die CAPolicy.inf nicht notwendig. In den meisten Fällen sind die Standardeinstellungen aber unpassend.

Die CAPolicy.inf wird beim Setup im Ordner %windir% gesucht. Was mir nach wie vor passiert, ist die ausgeblendete Dateierweiterung. Bitte daran denken, dass bei einem neuen System nicht eine capolicy.inf.txt verwendet wird. In diesem Fall wird das File ignoriert, und die Zertifizierungsstelle wird mit Standardeinstellungen installiert.

 

[Version]
Signature= „$Windows NT$“

[PolicyStatementExtension]
Policies = LegalPolicy
Critical = 0

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = „Root CA Legal policy statement“
URL = „http://pki.spielwiese.local/CertEnroll/rootLegalPolicy.txt“
[certsrv_server]
renewalkeylength=4096
RenewalValidityPeriodUnits=30
RenewalValidityPeriod=years

CRLPeriod = weeks
CRLPeriodUnits = 27
CRLDeltaPeriod = hours
CRLDeltaPeriodUnits = 0
DiscreteSignatureAlgorithm = 1

 

CRLDeltaPeriodUnits=0 deaktiviert die Veröffentlichung von Delta Sperrlisten.

Der Bereich [LegalPolicy] ist für Certificate Policies (CP) und Certificate Practice Statements (CPS) vorgesehen. Hinter der URL kann im Anschluss ein angepasstes Dokument gelegt werden. Die URL kann aber auch ins leere laufen, Hauptsache die URL wird in die Zertifikate übernommen.

Die Sperrlistenverteilungspunkte (Certificate Revocation List Distribution Point, CDP) und Zugriffe auf Stelleninformationen (Authority Information Access, AIA) könnten mit den beiden Punkten unten bereits in der CAPolicy.inf definiert werden. Ich werde die Konfiguration aber manuell durchführen, um zu vermeiden, dass bei einem erneuten Einlesen der .inf Datei eine manuelle Änderung zurückgesetzt wird.

[CRLDistributionPoint]
URL=http://pki.spielwiese.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

[AuthorityInformationAccess]
URL=http://pki.spielwiese.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

die Platzhalter in AIA und CDP werden in der Registry in entsprechende Variablen gesetzt. Die Registry Einstellungen werden beim Starten der CA eingelesen.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_Name>

%1 ServerDnsName
%2 ServerShortName
%3 CaName
%4 CertificateName
%5 DomainName
%6 ConfigDN
%7 CATruncatedName
%8 CRLNameSuffix
%9 DeltaCRLAllowed
%10 CDPObjectClass
%11 CAObjectClass

2. Installation  und Konfiguration der Rolle

die Installation und Konfiguration erfolgt mit der Powershell

Import-Module ServerManager

Add-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority -CAType StandaloneRootCA -KeyLength 4096 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 30 -CACommonName Root-CA -CryptoProviderName „RSA#Microsoft Software Key Storage Provider“

 

 3. Überprüfen ob die CAPolicy.inf angewendet wurde

 

 

in den Eigenschaften des Root Zertifikates, ist die Legal Policy, hinterlegt. Die Verzichtserklärung zeigt die Eigenschaften des Punktes Notice, der Button Weitere Informationen öffnet die angegeben URL. Beides wurde in der CAPolicy.inf definiert.

in den Eigenschaften der gesperrten Zertifikate überprüfen, ob der in der CAPolicy.inf vorgegebene Intervall für das Veröffentlichen der Sperrliste übernommen wurde, und keine Veröffentlichung von Deltasperrlisten durchgefürht wird.

4. Validity Period

mit dem Command Line Tool Certutil wird die maximale Gültigkeitsdauer auszustellender Zertifikate ausgelesen. Dieser Wert gibt an, wie lange das Zertifikat für die Enterprise CA gültig sein darf

# get validity period
certutil -getreg ca\validityperiod
certutil -getreg ca\validityperiodunits

 

Standard ist ein Jahr. Der Wert wird mit dem selben Befehl, jedoch mit der Option setreg angepasst

# set validity period
certutil -setreg ca\validityperiodunits 10

es sollte immer die Restlaufzeit des aktuellen Root CA Zertifikats im Auge behalten werden. Die Laufzeit eines auszustellenden Zertifikates kann nicht die Laufzeit des Zertifikats der ausstellenden CA übersteigen. Hat z.B. das Zertifikat der Root CA noch 8 Jahre Laufzeit, kann es maximal Zertifikate mit 8 Jahren Laufzeit ausstellen. Als Faustregel gilt daher, dass übergeordnete Instanzen mindestens eine doppelt so lange Laufzeit haben, und nach Ablauf der Hälfte erneuert werden. In meinem Setup sind das folgende:

• Root CA 30 Jahre
• Sub CA 10 Jahre
• Laufzeit für Templates in Sub CA maximal 5 Jahre

5. Konfiguration von CDP und AIA in der Root CA

in den Eigenschaften der Root CA unter dem Reiter Erweiterungen werden die Sperrlisten Verteilungspunkte und Zugriff auf Stelleninformationen angepasst, die in ausgestellten Zertifikaten eingetragen werden.

CDP

 

lokale Partition: Standard %windir%\system32\CertSrv\CertEnroll\….

•  Sperrliste Veröffentlichen

file://  (eine Abfrage über UNC Pfade funktioniert technisch nicht)

• keine Option wählen

ldap:  Eintrag entfernen, und an die Domäne angepassten Eintrag setzen (z.B. spielwiese.local)
ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=spielwiese,DC=local

•  In CDP Erweiterung des ausgestellten Zertifikats einbeziehen

http:// Eintrag entfernen, und an die Domäne angepassten Eintrag setzen (DNS Alias „pki“ auf Webserver)
http://pki.spielwiese.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

• In CDP Erweiterung des ausgestellten Zertifikats einbeziehen

 

 

 

---

AIA

 

lokale Partition: Standard %windir%\system32\CertSrv\CertEnroll\….

• keine Option wählen

file://

• keine Option wählen

ldap:  Eintrag entfernen, und an die Domäne angepassten Eintrag setzen (z.B. spielwiese.local)
ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=spielwiese,DC=local

• In AIA Erweiterung des ausgestellten Zertifikats einbeziehen

http:// Eintrag entfernen, und an die Domäne angepassten Eintrag setzen (DNS Alias „pki“ auf Webserver)
http://pki.spielwiese.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

• In AIA Erweiterung des ausgestellten Zertifikats einbeziehen

---

Damit die Änderungen wirksam werden, wird beim Button Übernehmen ein Neustart des Zertifizierungsstelle angefordert.

mit der Command Line können die gesetzten Pfade aus der Registry ausgelesen werden

certutil -getreg  CA\CRLPublicationURLs
certutil -getreg  CA\CACertPublicationURLs

Unter diesem Registry Pfad liegen die Konfigurationsparameter, es ist nicht verkehrt ein Backup mittels Export Funktion im Registry Editor zu machen.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_Name>

 

6. Publish Root CA Cert und CRL

unter C:\Windows\System32\CertSrv\CertEnroll liegen zwei Files, ein .crl (Sperrliste) sowie ein .crt (Zertifikat).

Der Root-CA Server verfügt im besten Fall über keine Netzwerkverbindung. Er wird nur kurz, alle 27 Wochen oder vorher, zur Erneuerung der Sperrliste hochgefahren. Wenn eine aktuelle Sperrliste erstellt, und wegkopiert wurde, kann der Server wieder in den Safe. Das Zertifikat wird erst in 15 Jahren erneuert

Die Files werden, für den http Abruf auf den Webserver kopiert, in das Verzeichnis c:\inetpub\CertEnroll, und sind über http://pki.spielwiese.local/Certenroll abrufbar. Für die Veröffentlichung im Active Directory, werden die selben Dateien auf ein Domain Member mit ldap Zugriff kopiert, z.b. den Enterprise CA Server.

Mit den folgenden Command Line Befehlen werden die Dateien in die Configuration Partition des Active Directory aufgenommen. Dies bewirkt im Hintergrund, dass das Zertifikat in den Zertifikatsspeicher für vertrauenswürdige Stammzertifizierungsstellen aller Domänen Computer aufgenommen wird

certutil -f -dspublish <certificate_file>.crt <Root-CA Name>
certutil -f -dspublish <revocation_list_file>.crl <Root-CA Servername>

Der Root-CA Servername muss der NetBios Kurzname des Servers sein. Durch die Angabe von CN=<ServerShortName> im Pfad der Sperrlisten Verteilungspunkte, wird in der Configuration Partition des AD unter CDP der Servername erwartet.

Das wars fast schon, die CA ist konfiguriert, und das Zertifikat, sowie die Sperrliste ist an zwei unabhängigen Abrufmöglichkeiten hinterlegt worden. Wenn im nächsten Schritt das Enterprise CA Zertifikat ausgestellt wurde, wird damit, die darin hinterlegten Pfade auf Richtigkeit geprüft. Anschliessend wird die Root CA heruntergefahren.

 

Enterprise CA

 

1. CAPolicy.inf

Eine CAPolicy.inf wird wie vorher bei der Root CA beim Setup im Ordner %windir% gesucht.

[Version]
Signature= „$Windows NT$“

[PolicyStatementExtension]
Policies = LegalPolicy
Critical = 0

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = „Enterprise CA Legal policy statement“
URL = „http://pki.spielwiese.local/CertEnroll/subLegalPolicy.txt“

[AuthorityInformationAccess]
Empty = true  ; only Required for Windows Server 2003
;URL = http://%1/Public/My CA.crt
;URL = file://\\%1\Public\My CA.crt
Critical = true

[CRLDistributionPoint]
Empty = true; Only required for Windows Server 2003
;URL = http://%1/Public/My CA.crl
;URL = file://\\%1\Public\My CA.crl
Critical = true
[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
CRLPeriod = days
CRLPeriodUnits = 3
CRLDeltaPeriod = hours
CRLDeltaPeriodUnits = 4
LoadDefaultTemplates=0

2. Installation  und Konfiguration der Rolle

Add–WindowsFeature ADCS–Cert–Authority –IncludeManagementTools

Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCA -HashAlgorithmName SHA256 -CryptoProviderName „RSA#Microsoft Software Key Storage Provider“ -CACommonName Enterprise-CA-Spielwiese -ParentCA 2012R2-CA01\Root-CA-Spielwiese

 

kommt der Fehler „Install-AdcsCertificationAuthority : Der private Schlüssel „Enterprise-CA-Spielwiese“ besteht bereits.“ kann der Key aus vorangegangener Installation mit der Option -OverwriteExistingKey überschrieben werden

WARNUNG: Die Installation der Active Directory-Zertifikatdienste ist nicht abgeschlossen. Fordern Sie mithilfe der Anforderungsdatei „C:\<request_file_name>.req“ ein Zertifikat von der übergeordneten Zertifizierungsstelle an, um die Installation abzuschließen. Installieren Sie das Zertifikat anschließend mit dem Zertifizierungsstellen-Snap-In. Klicken Sie dazu mit der rechten Maustaste auf den Knoten mit dem Namen der Zertifizierungsstelle, und klicken Sie dann auf „Zertifizierungsstellenzertifikat installieren“. Der Vorgang wurde erfolgreich beendet. 0x0 (WIN32: 0)

 

das Request File der Enterprise CA wird auf die Root CA kopiert, und dort über das Zertfizierungsstellen Snap-In eingereicht. (Alternativ über die Command Line certreq -submit <request_file_name>.req)

Unter dem Punkt Ausstehende Anforderungen unterhalb der Root-CA, wird mit einem Rechtsklick der Request bestätigt. Das Zertifikat wird unter Ausgestellte Zertifikate abgelegt.

Die Gültigkeit des Zertifikats ist 10 Jahre. Ist dies nicht der Fall, ist entweder die ValidityPeriod der Root CA, oder die RenewalValidityPeriod der Enterprise CA zu niedrig. Im Fall der Root CA den Wert neu setzen, und Request wiederholen. Im Fall der Enterprise CA, nach Änderung ein neues Request File generieren (Rechtsklick auf Enterprise CA).

Die ValidityPeriod der Root CA lässt sich, wie oben beschrieben mit  certutil -getreg ca\validityperiod und certutil -getreg ca\validityperiodunits ausgeben. Die drei Werte für RenewalKeyLength, RenewalValidityPeriod und RenewalValidityPeriodUnits der Enterprise CA stehen nicht in der Registry, und können somit auch nicht mit certutil ausgelesen werden. Diese Werte werden bei der Installation der CA, bzw. Verlängerung des Enterprise Zertifikates aus der CAPolicy.inf eingelesen. Wie die Werte aus dem System ausgelesen werden können, ist mir nicht bekannt.

Zum Exportieren des Zertifikats unter Ausgestellte Zertifikate, Eigenschaften des Zertifikats, Reiter Details, „In Datei kopieren“ –> DER-codiert-binär X.509 (.CER). Das Zertifikat wird jetzt zur Enterprise CA kopiert, und beim Starten der CA, über das Zertifizierungsstellen Snap-In, angegeben.

 

3. Check List for Root CA

Die in der Root CA konfigurierten Pfade für AIA und CRL (jeweils ein http und ein ldap) sind im Zertifikat der Enterprise CA hart codiert. Um die Erreichbarkeit dieser Pfade zu prüfen, wird das Zertifikat der Enterprise CA mit dem folgenden Befehl aufgerufen:

certutil -URL <certificate.crt>

mehr Details bekommt man mit dem selben Tool auf der Commandline:

certutil -f -verify -urlfetch <certname>.crt

für eine Fehlersuche lässt sich der Cache einsehen bzw. löschen

.crt –> certutil -urlcache / certutil -urlcache * delete
.crl –> certutil -urlcache crl / certutil -urlcache crl delete

Ein Blick in die Verfügbaren Parameter (certutil /?) zeigt den Umfang dieses mächtigen Tools!

 

4. Konfiguration von CDP und AIA in der Enterprise CA

CDP

lokale Partition: Standard %windir%\system32\CertSrv\CertEnroll\….

• Sperrliste an diesem Ort veröffentlichen
• Deltasperrlisten an diesem Ort veröffentlichen

ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

• Sperrliste an diesem Ort veröffentlichen
• In alle Sperrlisten einbeziehen. Legt fest, …
• In Sperrlisten einbeziehen. Wird z. Suche von Deltasperrlisten verwendet
• In CDP-Erweiterung des ausgestellten Zertifikats einbeziehen
• Deltasperrlisten an diesem Ort veröffentlichen

http:// Eintrag entfernen, und an die Domäne angepassten Eintrag setzen (DNS Alias “pki” auf Webserver)
http://pki.spielwiese.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

• In Sperrlisten einbeziehen. Wird z. Suche von Deltasperrlisten verwendet
• In CDP-Erweiterung des ausgestellten Zertifikats einbeziehen

neuen an die Domäne angepassten Eintrag setzen (kopiert CRL und CRL+ über SMB Share)
\\pki.spielwiese.local\Certenroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

• Sperrliste an diesem Ort veröffentlichen
• Deltasperrlisten an diesem Ort veröffentlichen

---

AIA

lokale Partition: Standard %windir%\system32\CertSrv\CertEnroll\…. –> keine Option

file://… –> keine Option

ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

• In AIA-Erweiterung des ausgestellten Zertifikats einbeziehen

http:// Eintrag entfernen, und an die Domäne angepassten Eintrag setzen (DNS Alias “pki” auf Webserver)
http://pki.spielwiese.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

• In AIA-Erweiterung des ausgestellten Zertifikats einbeziehen

5. Publish Enterprise CA Cert

da der Server der Enterprise CA ein Domain Member ist, geht das meiste automatisch. Die Sperrlisten, sowie Deltasperrlisten werden in LDAP sowie auf den HTTP Server per UNC Pfad aktualisiert. Das Zertifikat wird bei Erstellung automatisch im AD abgelegt. Das kopieren auf den HTTP Server muss manuell erfolgen.

%windir%\system32\CertSrv\CertEnroll\<Enterprise_CA_cert>.crt –> \\<webserver>\CertEnroll\

Eine gute Übersicht über die Umgebung bietet das Snap-In Unternehmens-PKI in der MMC

Ist die Deltasperrliste vorhanden, aber nicht abrufbar liegt das vermutlich an der nicht aktivierten URL_DOUBLE_ESCAPED Funktion.

siehe weiter oben „Enable IIS Double Escaping“

 

6. Check List for Enterprise CA

zur Überprüfung der korrekten Pfade der Enterprise CA wird ein durch diese CA ausgestelltes Zertifikat geprüft. Die AIA Einträge sind analog zur Root CA, der CDP hat zusätzlich Delta Sperrlisten.

 certutil -URL <certificate.crt>