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:
Im Server Manager wird die Rolle „Active Directory -Zertifikatsdienste“ hinzugefügt
Als Rollendienst wird nur die Zertifizierungsstelle benötigt
Da es sich bei dem Server um kein Active Directory Mitglied handelt, kann nur „Eigenständig“ als Installationstyp gewählt werden
Da es sich um die Root-CA handelt, wird bei Zertifizierungsstellentyp „Stammzertifizierungsstelle“ ausgewählt
Und da wir keine Migration oder Recovery einer CA durchführen wollen, erstellen wir einen neuen privaten Schlüssel
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.
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…
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.
Den Rest der Dialoge mit „Weiter“ bestätigen. Sobald die Installation abgeschlossen ist, haben wir eine Root-CA.
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:
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)
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