8
Enterprise CA error
Hallo,
ich setze seit Anfang des Jahres eine Enterprise CA ein.
leider hatte ich vorher nie wirklich viel mit Zertifikaten zu tun, daher war die Einrichtung für mich ein echter Graus.
naja, ich habe es anhand einer Step-by-Step Anleitung letztendlich doch hinbekommen, dies funktionierte auch einwandfrei bis letzte Woche.
Im Einsatz sind folgende Server:
Root-CA - wie der Name schon sagt meine Root CA, Offline
Server 04 - Meine Sub CA
Server 09 - darauf läuft DirSync
nun ist mir aufgefallen, dass auf 'Server 04' der Dienst Active Directory Certification Services nicht mehr läuft und sich auch nichtmehr starten lässt.
Das Eventlog bringt folgende Meldung:
"Active Directory Certificate Services did not start: Could not load or verify the current CA certificate. Company Issuing CA The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)."
schaue ich mir unter dem Server die Enterprise PKI an sehe ich foldende Fehler:
CDP Location #1 Unable to download
CDP Location #2 Expired
ich meine das war schon seit beginn so und hat nicht zwingend mit dem verhindern des startens von ADCS zu tun.
Nun zu dem was ich bereits versucht habe:
- ich habe testweise mal alle Server neu gestartet, aber wie zu befürchten hat das nicht wirklich funktioniert.
- außerdem habe ich folgenden Hinweis getestet:
generate a new Root CA crl File on your Root CA in the GUI right click on "revoked Certificates", "All Tasks", "Publish" go to local Filessystem C:\Windows\system32\Certsrv\Certenroll and copy the new CRL to a Domain Member Server and run:
certutil -dspublish -f "yourCRLfile.crl"
dabei erhalte ich den Fehler:
ldap: 0x22: 0000208F: NameErr; DSID-03100225, Problem 2006 (BAD_NAME), data 8350, best match of: 'CN=Public Key Services,CN=Services,&6&10'
verstehe ich jetzt nicht ganz ?! :S
gruß
fluluk
ich setze seit Anfang des Jahres eine Enterprise CA ein.
leider hatte ich vorher nie wirklich viel mit Zertifikaten zu tun, daher war die Einrichtung für mich ein echter Graus.
naja, ich habe es anhand einer Step-by-Step Anleitung letztendlich doch hinbekommen, dies funktionierte auch einwandfrei bis letzte Woche.
Im Einsatz sind folgende Server:
Root-CA - wie der Name schon sagt meine Root CA, Offline
Server 04 - Meine Sub CA
Server 09 - darauf läuft DirSync
nun ist mir aufgefallen, dass auf 'Server 04' der Dienst Active Directory Certification Services nicht mehr läuft und sich auch nichtmehr starten lässt.
Das Eventlog bringt folgende Meldung:
"Active Directory Certificate Services did not start: Could not load or verify the current CA certificate. Company Issuing CA The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)."
schaue ich mir unter dem Server die Enterprise PKI an sehe ich foldende Fehler:
CDP Location #1 Unable to download
CDP Location #2 Expired
ich meine das war schon seit beginn so und hat nicht zwingend mit dem verhindern des startens von ADCS zu tun.
Nun zu dem was ich bereits versucht habe:
- ich habe testweise mal alle Server neu gestartet, aber wie zu befürchten hat das nicht wirklich funktioniert.
- außerdem habe ich folgenden Hinweis getestet:
generate a new Root CA crl File on your Root CA in the GUI right click on "revoked Certificates", "All Tasks", "Publish" go to local Filessystem C:\Windows\system32\Certsrv\Certenroll and copy the new CRL to a Domain Member Server and run:
certutil -dspublish -f "yourCRLfile.crl"
dabei erhalte ich den Fehler:
ldap: 0x22: 0000208F: NameErr; DSID-03100225, Problem 2006 (BAD_NAME), data 8350, best match of: 'CN=Public Key Services,CN=Services,&6&10'
verstehe ich jetzt nicht ganz ?! :S
gruß
fluluk
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 287306
Url: https://administrator.de/forum/enterprise-ca-error-287306.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
8 Kommentare
Neuester Kommentar
Also habe nun die Erkenntnis, das die Zertifikate nichts mit DirSync zu tun hatten, es wurde ledeglich von einem Benutzer ausgeführt, dessen Kennwort abgelaufen ist.
Ich habe das Problem nun behoben.
Allerdings bestehen die Probleme mit den Zertifikatsservern weiterhin.
mal schauen ob ich den Titel anpassen kann, da Office 365 jetzt nichtmehr viel damit zu tun hat.
Ich habe das Problem nun behoben.
Allerdings bestehen die Probleme mit den Zertifikatsservern weiterhin.
mal schauen ob ich den Titel anpassen kann, da Office 365 jetzt nichtmehr viel damit zu tun hat.
Hallo,
ich vermute, dass deine Root-CA nicht Domänenmitglied ist; dies sollte auch so sein. Was in den meisten Anleitung unterschlagen wird ist, dass bei der Konfiguration der Root-CA der Pfad zur Domäne trotzdem eingetragen werden muss wenn man LDAP als Sperrlistenverteilungspunkt (CDP) verwenden will. Dies geschieht mit den Befehlen (die Domäne heißt hier domain.local -> dies musst du entsprechend ersetzen!):
Erst wenn der Domänenpfad im Root-Zertifikat drinsteht kann er über LDAP auf den Sperrserver zugreifen. Entweder fängst du von vorne an oder du musst das Zertfifizierungsstellenzertifikat der Root erneuern. Dann hast du aber ein "Zertifikat Nr. 1".
Der dspublish vom Root-Zertifikat, den du auf der Sub-CA (Domänenmitglied) machen musst/solltest, schlägt fehl, weil im Zertifikat kein Domänenpfad drin steht. Ich wusste das am Anfang auch nicht als ich denselben Fehler hatte.
Wenn der Sperrserver offline ist, heißt das nur dass er keinen der eingetragenen CDP erreichen kann. Den lokalen CDP (C:\Windows\System32\.......) hast du aber nicht gelöscht?
Ich hatte diese Anleitung benutzt (mehrteilig - unbedingt die Kommentare dazu lesen) : Server 2008/2012: PKI installieren (Teil 1).
Dort fehlt die Info.
Unter Server 2012 ist das Erstellen einer CAPolicy.inf zwar nicht mehr notwendig, aber ich würde sie allein aufgrund der Renewal-Parameter trotzdem anlegen. Diese kann man nur dort und vor der ADCS-Installation festlegen, nachträglich geht das nicht mehr.
Wird die PKI nur domänenintern verwendet?
Gruß
Winary
ich vermute, dass deine Root-CA nicht Domänenmitglied ist; dies sollte auch so sein. Was in den meisten Anleitung unterschlagen wird ist, dass bei der Konfiguration der Root-CA der Pfad zur Domäne trotzdem eingetragen werden muss wenn man LDAP als Sperrlistenverteilungspunkt (CDP) verwenden will. Dies geschieht mit den Befehlen (die Domäne heißt hier domain.local -> dies musst du entsprechend ersetzen!):
certutil -setreg CA\DSConfigDN „CN=Configuration,DC=domain,DC=local“
certutil -setreg CA\DSDomainDN „DC=domain,DC=local“Erst wenn der Domänenpfad im Root-Zertifikat drinsteht kann er über LDAP auf den Sperrserver zugreifen. Entweder fängst du von vorne an oder du musst das Zertfifizierungsstellenzertifikat der Root erneuern. Dann hast du aber ein "Zertifikat Nr. 1".
Der dspublish vom Root-Zertifikat, den du auf der Sub-CA (Domänenmitglied) machen musst/solltest, schlägt fehl, weil im Zertifikat kein Domänenpfad drin steht. Ich wusste das am Anfang auch nicht als ich denselben Fehler hatte.
Wenn der Sperrserver offline ist, heißt das nur dass er keinen der eingetragenen CDP erreichen kann. Den lokalen CDP (C:\Windows\System32\.......) hast du aber nicht gelöscht?
Ich hatte diese Anleitung benutzt (mehrteilig - unbedingt die Kommentare dazu lesen) : Server 2008/2012: PKI installieren (Teil 1).
Dort fehlt die Info.
Unter Server 2012 ist das Erstellen einer CAPolicy.inf zwar nicht mehr notwendig, aber ich würde sie allein aufgrund der Renewal-Parameter trotzdem anlegen. Diese kann man nur dort und vor der ADCS-Installation festlegen, nachträglich geht das nicht mehr.
Wird die PKI nur domänenintern verwendet?
Gruß
Winary
oh...
coole Anleitung, danke!
leider komme ich heute nicht mehr dazu das zu testen, aber klingt logisch, dass es bis jetzt nicht funktioniert hat.
die PKI wird nur domänintern genutzt, das ist richtig.
die schritte die Du mir vorgeschlagen hast sind mir auch neu, ich denke nicht das ich die so umgesetzt habe.
Vielen Dank nochmal
gruß
fluluk
coole Anleitung, danke!
leider komme ich heute nicht mehr dazu das zu testen, aber klingt logisch, dass es bis jetzt nicht funktioniert hat.
die PKI wird nur domänintern genutzt, das ist richtig.
die schritte die Du mir vorgeschlagen hast sind mir auch neu, ich denke nicht das ich die so umgesetzt habe.
Vielen Dank nochmal
gruß
fluluk
ADCS war mir bis vor kurzem auch ein Neuland. 
Durch einen Kundenauftrag musste ich mich damit tiefergehend beschäftigen. Mittlerweile habe ich das Prinzip aber verstanden. So komplex wie es mir am Anfang schien ist es gar nicht; alles sehr logisch.
Ärgerlich ist nur die Tatsache, dass man Zertifikate nachträglich nicht ändern kann, z.B. CDP-Änderungen. Das soll aber auch so sein und ist gut so. Nur muss man immer von vorne anfangen wenn man nicht irgendwann das "Zertifikat Nr. 20" haben will bis es funktioniert:
Wenn man Änderungen wie eine CDP-Änderung in den Zertifizierungsstelleneigenschaften macht, werden diese Änderungen nur in künftigen Zertifikaten eingetragen. Logischerweise werden die Änderungen in bisher ausgestellten Zertifikate sowie im Zertifizierungsstellenzertifikat nicht durchgeführt. Will man die Änderung auch in diesem Zertifikat muss es erneuert werden und das erneuerte Zertifikat muss an alle Clients so wie das vorige verteilt werden. Dieses hat dann eine Zertifikatsnummer höher. Ich persönlich finde es unschön wenn man ein "Zertifikat Nr. 1" hat, ich bevorzuge Neuinstallation; das ist ja schnell gemacht wenn man weiß wie es richtig geht.
Gruß
Winary
Durch einen Kundenauftrag musste ich mich damit tiefergehend beschäftigen. Mittlerweile habe ich das Prinzip aber verstanden. So komplex wie es mir am Anfang schien ist es gar nicht; alles sehr logisch.Ärgerlich ist nur die Tatsache, dass man Zertifikate nachträglich nicht ändern kann, z.B. CDP-Änderungen. Das soll aber auch so sein und ist gut so. Nur muss man immer von vorne anfangen wenn man nicht irgendwann das "Zertifikat Nr. 20" haben will bis es funktioniert:
Wenn man Änderungen wie eine CDP-Änderung in den Zertifizierungsstelleneigenschaften macht, werden diese Änderungen nur in künftigen Zertifikaten eingetragen. Logischerweise werden die Änderungen in bisher ausgestellten Zertifikate sowie im Zertifizierungsstellenzertifikat nicht durchgeführt. Will man die Änderung auch in diesem Zertifikat muss es erneuert werden und das erneuerte Zertifikat muss an alle Clients so wie das vorige verteilt werden. Dieses hat dann eine Zertifikatsnummer höher. Ich persönlich finde es unschön wenn man ein "Zertifikat Nr. 1" hat, ich bevorzuge Neuinstallation; das ist ja schnell gemacht wenn man weiß wie es richtig geht.
Gruß
Winary
Hallo nochmal,
habe mich gerade dazu entschlossen das Zertifikat neu zu erstellen, die SubCA ist allerdings in der Domäne eingebunden. Daher würde mich interessieren ob ich die SubCAs einfach deinstallieren kann und die VM Server entsprechend löschen kann oder erhalte ich dann einen Verwaisten Zustand der Domain?
Ich hatte es damals anhand dieses HowTos gemach:
http://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs- ...
gruß
fluluk
habe mich gerade dazu entschlossen das Zertifikat neu zu erstellen, die SubCA ist allerdings in der Domäne eingebunden. Daher würde mich interessieren ob ich die SubCAs einfach deinstallieren kann und die VM Server entsprechend löschen kann oder erhalte ich dann einen Verwaisten Zustand der Domain?
Ich hatte es damals anhand dieses HowTos gemach:
http://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs- ...
gruß
fluluk
Hallo,
ich würde erstmal herausfinden was mit den eingetragenen CDPs nicht stimmt.Du sagtest ja, dass es vorher funktioniert hat. Der erste CDP ist meistens der lokale Pfad zum Certenroll-Ordner; in deinem Fall auf dem Server 04. Schau mal ob irgendwas mit den Berechtigungen nicht stimmt -> die Zertifizierungsstelle kann nicht auf die zugreifen.
Der zweite im Standard der LDAP-Pfad, ergo die Veröffentlichung im AD.
Ich nehme an, dass du den dritten und vierten Standardeintrag gelöscht hast. Das ist zum Einen der Pfad zur Certenroll-Freigabe (File) auf deinem Server 04 und zum anderen die URL (HTTP).
Mir gibt aber zu denken, dass dein zweiter CDP als abgelaufen angezeigt wird. Was hast du denn für ein Veröffentlichungsintervall von der Root- und Sub-Sperrliste? Was steht denn da wenn du die CRL-Dateien öffnest? Ist da die Gültigkeit abgelaufen?
Wie gesagt, du musst die Ursache finden warum die Zertifizierungsstelle die Sperrlisten nicht erreichen können bzw. warum sie abgelaufen sind. Vielleicht hast du ja 1 Jahr als Intervall angegeben, welches jetzt abgelaufen ist und es hat bisher nur funktioniert weil die Sperrlisten nicht erneuert werden mussten.
ich würde erstmal herausfinden was mit den eingetragenen CDPs nicht stimmt.Du sagtest ja, dass es vorher funktioniert hat. Der erste CDP ist meistens der lokale Pfad zum Certenroll-Ordner; in deinem Fall auf dem Server 04. Schau mal ob irgendwas mit den Berechtigungen nicht stimmt -> die Zertifizierungsstelle kann nicht auf die zugreifen.
Der zweite im Standard der LDAP-Pfad, ergo die Veröffentlichung im AD.
Ich nehme an, dass du den dritten und vierten Standardeintrag gelöscht hast. Das ist zum Einen der Pfad zur Certenroll-Freigabe (File) auf deinem Server 04 und zum anderen die URL (HTTP).
Mir gibt aber zu denken, dass dein zweiter CDP als abgelaufen angezeigt wird. Was hast du denn für ein Veröffentlichungsintervall von der Root- und Sub-Sperrliste? Was steht denn da wenn du die CRL-Dateien öffnest? Ist da die Gültigkeit abgelaufen?
Wie gesagt, du musst die Ursache finden warum die Zertifizierungsstelle die Sperrlisten nicht erreichen können bzw. warum sie abgelaufen sind. Vielleicht hast du ja 1 Jahr als Intervall angegeben, welches jetzt abgelaufen ist und es hat bisher nur funktioniert weil die Sperrlisten nicht erneuert werden mussten.
Hallo,
Gibt es was Neues?
Gibt es was Neues?
hallo,
bin leider noch nicht dazu gekommen, werde es aber diese Woche auf jedenfall noch angehen.
sorry
bin leider noch nicht dazu gekommen, werde es aber diese Woche auf jedenfall noch angehen.
sorry
