A certification authority is quickly installed under Windows Server. Essentially, the "Certification authority" role is added, "Next" is clicked a few times and you have a CA that can issue all possible certificates. So you have a PKI, which works, but is bad.
A PKI and its CAs must be well planned, and legal, organizational and administrative matters must be taken into account. Quickly installing a CA and issuing certificates for all kinds of purposes without having thought about revocation lists, security and requirements beforehand can quickly end fatally. Especially when it comes to issues such as smartcard authentication or encryption (Bitlocker, EFS, S/MIME).
Of course, I can't take the careful planning and installation of a PKI off anyone's hands, but this howto at least provides a solid basis for a PKI that can meet many requirements. It's certainly better than the "Next...Next...Next...Finish" method.
In this howto, a 2-tier PKI consisting of an offline standalone CA and an Active Directory integrated sub-CA (company CA) is installed. This howto also contains a few adjustments to increase security and avoid problems.
Root CA
This howto is about a 2-tier PKI, so the root CA (or root certification authority) must first be installed and configured. This requires a Windows Server 2008 (R2) or Windows Server 2012 (R2), the Standard Edition is completely sufficient. In productive environments, a VM is recommended, as the root CA is rarely required. Normally, the root CA is offline, switched off, locked in the vault and buried. A VM is therefore a good option, as the vault and the hole can be somewhat smaller.
A Windows Server 2008 Standard or Windows Server 2012 Standard is sufficient for the installation. I have installed a Server 2008 R2, but the configuration is identical for Server 2012. The server is not an Active Directory member, only all updates have been installed so far.
Before the root CA is installed, the CAPolicy.inf file must be created. I use a CAPolicy.inf with the following content:
[Version] Signature = "$Windows NT$" [CRLDistributionPoint] Empty = true [AuthorityInformationAccess] Empty = true [certsrv_server] RenewalKeyLength = 4096 RenewalValidityPeriodUnits = 20 RenewalValidityPeriod = years
The INF file specifies that the CA does not have an AIA and CDP. This information is important as it is an offline root CA. Clients therefore do not need to check the root CA's revocation list or AIA. Furthermore, the use of keys is restricted so that the Root CA can only sign Sub CAs. After all, the Root CA is not supposed to issue certificates for other purposes. While you are at it, you can also make the settings for renewing the root certificate. If the certificate is renewed once, it will only be extended by 2 years without these settings. This would also mean that no more certificates can be issued that have a longer term than 2 years.
A file with the name "CAPolicy.inf" must therefore be created, which contains the content shown above. The CAPolicy.inf must then be copied to the Windows directory (C:\Windows). The CAPolicy.inf is read in during the installation of the certification authority, it will not work afterwards.
As soon as the CAPolicy.inf is in the Windows directory, the CA can be installed:
The "Active Directory Certificate Services" role is added in the Server Manager
Only the certification authority is required as a role service
As the server is not an Active Directory member, only "Standalone" can be selected as the installation type
As this is the root CA, "Root certification authority" is selected for the certification authority type
And since we do not want to migrate or recover a CA, we create a new private key
The cryptography tab is an important point, SHA1 is considered cracked and will no longer be supported by Microsoft as a hash algorithm in the future. To be on the safe side for the next few years, SHA256 and 4096 bits are selected here as the key length. 2048-bit keys are now considered the minimum.
Now assign a descriptive name for the CA. The host name of the server should not be part of the CA name, after all, nobody needs to know the host name of our root CA...
And now to the final question: How long should the CA be valid for? Not too short and not too long, the shorter the more secure the more effort. The longer, the less secure, the less effort. I would set 5 years as the minimum, 20 years as the maximum.
Confirm the rest of the dialogs with "Next". As soon as the installation is complete, we have a root CA.
The CA can now be configured conveniently from the command line (Attention: Adjustments necessary, see below):
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
The commands above can be copied into a .BAT file and must then be adapted slightly:
Line 3: The Active Directory configuration partition must be specified here. My AD domain is frankysweb.local. Therefore it is "CN=Configuration,DC=frankysweb,DC=local" for me. The corresponding entry can be determined from a domain controller using ADSI-Edit:
Line 17 and line 20: If you want to ensure that the revocation list can also be accessed by external clients (important for clients without a connection to the AD), you must specify a web server at the end of the line that can be accessed from the Internet. If you only need to serve AD members, you can remove the end of the line (not the whole line, just the one from "n2"). However, I recommend entering a valid URL, more on this later.
Finally, the revocation list and the root CA certificate must be copied to the server that will later become the sub-CA. So I copy the files from "C:\Windows\System32\CertSrv\CertEnroll" to a server that is an ActiveDirectory member. The certificates must be imported there (part 2)
So, now we have a root CA. Next up is the Active Directory integrated CA (Sub-CA) (Part 2)
Hallo, hatten Sie schon einmal eine 2 stufige PKI inplace geupdatet 2012 auf 2019? Es wird nicht empfohlen, könnte doch aber funktionieren mit einem Zwischenschritt über den Server 2016
Hallo,
Sie können nicht von 2012 auf 2019 direkt gehen, aber von 2012 R2 schon. Das sollte dann kein Problem darstellen, wenn man das Heraufstufen der Domänen- und Gesamtstrukturebene nicht vergisst. Evtl. müssen dann alle Zertifikatsvorlagen angepasst werden bzgl. Zielbetriebssystem.
Hallo, vielen Dank. Ja wir würden von 2012R2 updaten. Die Domäne ist schon auf 2019. Dann sollte es ja funktionieren. Wir haben eine 2 stufige PKI. Ist die Vorgehensweise 1. Root 2. Issue oder umgekehrt?
Hallo,
also ich habe nochmal nachgeschaut und das Inplace-Upgrade wird nur nicht empfohlen sondern dringend abgeraten. Spricht etwas dagegen die CA auf neue Server umzuziehen/zu migrieren? Dieser Weg ist supported und relativ einfach.
Hallo,
wenn es im Unternehmen eine AD-ROOT-CA gibt, man es jetzt auf eine 2-Stufige PKI umstellen muss/möchte.
Ist das Möglich?
Den Umzug der bestehenden PKI auf einen neuen Server ist wäre ja möglich. Dann hätte man aber keine 2-Stufige PKI.
Oder kann ich die bestehende PKI dann auf den SUB-CA installieren? (Private Key usw.)
Hallo,
wenn du eine bestehende PKI hast, dann ist deine Zertifizierungsstelle bereits eine ROOT-CA. Dann machst du einfach ab Teil 2 dieses Tutorials weiter und installierst eine weiter CA als untergeordnete Zertifizierungsstelle. Das Zertifizierungsstellenzertifikat der ROOT-CA sollte ja bereits im AD veröffentlicht sein. Vergiss nur nicht, dass das Zertifizierungsstellenzertifikat der SUB-CA nicht länger gültig sein kann als das Zertifizierungsstellenzertifikat der ROOT-CA. Und die ROOT-CA sollte ganz am Ende ausgeschalten werden, demnach sollte nichts anderes Wichtiges auf dem selben Server laufen.
Hallo,
was passiert mit den Zertifikaten, die von der Root CA schon ausgestellt wurden?
Beispiel NPS Server die haben jeweils ein Zertifikat erhalten. Wenn ich die Root CA dann offline nehme, ändert sich doch der Zertifizierungspfad. Dann muss der SUB bestätigen, dass das Zertifikat gültig ist, funktioniert das dann einfach so, oder sollte man besser die Zertifikate neu ausstellen?
Alle bisher ausgestellten Zertifikate müssen selbstverständlich von der neuen SUB-CA neu ausgestellt werden. Alle Zertifikatvorlagen sowie ggf. AIA und CDP müssen auf die SUB-CA umgemünzt werden. Alles muss funktionieren wenn die ROOT-CA aus ist. Dazu hilft das Onboard-Tool „pkiview.msc“ das auf jeder Windows-CA zur Verfügung steht.
Hallo,
ist es möglich eine bestehende einstufige AD-Root-CA zu ändern um die Gültigkeit des Root-Zertifikates zu verlängern?
Ich habe die CA ohne capolicy.inf erstellt, also mit Standardwerten und die Gültigkeitsdauer auf 5 Jahre festgelegt.
Nun würde ich aber gern das Root-Zertifikat auf 20 Jahre ausgestellt bzw. verlängert haben. Geht das?
Hallo,
dann musst du die CAPolicy.inf erstellen und die 20 Jahre setzen. Danach muss das Root-Zertifikat in der Zertifizierungsstelle erneuert werden.
„Root CA certificate validity can be set only during AD CS role installation. It is not possible to change root CA certificate validity without certificate renewal. If your root CA certificate is valid for 5 years (default) and you want to increase this value you must create (or edit existing) CAPolicy.inf file and place it to system root folder (by default C:\Windows).“
Quelle: https://www.sysadmins.lv/blog-en/how-to-change-ca-certificate-validity-period.aspx
Inhalt C:\Windows\CAPolicy.inf
#########################
[certsrv_server]
RenewalValidityPeriodUnits=20
RenewalValidityPeriod=years
#############################
Um sicher zu gehen die Werte manuell setzen
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod „years“
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
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
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
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
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
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
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
@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
@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
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
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