none
CA migration mit neuem Namen - Daher URL CDP LDAP-Eintrag für Certificate Revocation Check ungülitg RRS feed

  • Allgemeine Diskussion

  • Hallo Leute,

    wir haben ein "fieses" PKI Problem. Seit Tagen arbeite ich mich schon durch etliche Foren, allerdings ohne eine zufriedenstellende Lösung zu finden. Oder überhaupt eine Lösung.

    Wir haben eine einfache CA. Diese haben wir nach diversen Guides auf Windows Server 2019 migriert.

    Dummerweise steht in den CDP extensions aller bisher ausgegebenen Zertifikate die CRL-Quelle: ldap (alter Server).

    Da unser Server einen neuen Namen hat, stehen im LDAP (via ADSI-Edit) jetzt in der Konfig beide "Container".

    Die restliche CA läuft ohne Probleme, allerdings haben wir Fehlermeldungen bei diversen Diensten, da der alte Server nicht mehr existiert und die alten Zertifikate nach dem alten CDP LDAP Eintrag schauen und versuchen dort eine gültige CRL zu bekommen.

    Dienste, die in Mitleidenschaft gezogen wurden sind RDP und SCEP, welches ich für eine spezielle Lösung gerade in Betrieb nehmen wollte.

    Wir haben die alten ldap Eintrag in den Eigenschaften der neuen CA als Sperrlisten Verteilpunkt aufgenommen. mit den Haken bei "Sperrlisten - und Delta-Sperrlisten an diesem Ort veröffentlichen".

    Von unserem Verständis her sollte jede neu generierte CRL auch in diesem LDAP Container verfügbar sein. Ein schneller URL-Check mit "certutil -URL "ldap-phad" CRL gibt auch die Basissperrliste mit dem richtigen Servernamen als "ok" zurück. Im DNS haben wir einen AAA Host eintrag für den alten Server gemacht, der auf die neue CA verweist.

    In Pkiview wird der Pfad allerdings nicht angezeigt, was uns merkwürdig vorkommt.

    Haben wir etwas vergessen? Müssen wir euch einen Eintrag für AIA machen oder die CRL noch via "certutil -dspublish" verteilen, damit der Container veröffentlicht wird?

    Nach dem CDP eintrag hatten wir die Sperrlisten neu veröffenlticht, trotz allem können die Clients und Server nicht auf die URL zugreifen, weil sie offenbar nicht korrekt abgefragt wird, nicht befüllt ist o.ä..

    Da ich in eine Live-Umgebung bin, möchte ich nicht groß mit ein wenig Halbwissen großen Pfusch betreiben.

    PS: neue Zertifikate gehen inzwischen über HTTP ... und nicht über ldap...

    Nur wir bekomme ich den Revocation Check für den ldap-eintrag des alten Servers wieder hin?

    Besten Gruß

    Hecatonchires


    Donnerstag, 11. Juli 2019 22:46

Alle Antworten

  • Moin,

    ich weiß nicht, wie groß eure Umgebung ist, aber wäre angesichts des Aufwandes, den Du schon betrieben hast, die Flucht nach vorn (alle Zertifikate aus der neuen CA neu ausstellen) nicht einfacher und eleganter als solche Krücken zu bauen?

    Beschreib mal kurz, wie ihr migriert habt, oder verlinke bitte auf den Guide, den ihr befolgt habt.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 12. Juli 2019 05:23
  • Moin :)

    Wir haben diesen Guide benutzt, da wir nicht sicher waren, ob sich an dem Prozedere etwas zu 2019 geändert hat. Anscheinend ist der Kram allerdings seit Dekaden der selbe - zumindest in den wichtigen Grundzügen.

    https://www.infrastrukturhelden.de/microsoft-infrastruktur/active-directory/zertifizierungsdienste/umzug-einer-windows-zertifizierungsstelle-von-2012r2-auf-windows-server-2019.html

    Wie sich im Nachhinein zeigte, haben wir bei der ersten Annahme für die Migration vergeigt. Allerdings war das zu dem Zeitpunkt noch nicht klar.

    Wir haben seit der letzten Woche allerdings eine steile Lernkurve hingelegt, da wir wegen anderer Problemchen quasi nichts anderes mehr gemacht haben.

    Um auf den Kern Deiner Frage zurück zu kommen... "Ungern" würden wir einfach die "Lass alles automatisch neu ausstellen"-Karte ziehen.

    Die Krücke bis zum Auslaufen der alten Zertfikate wäre für uns aktuell die geschmeidigste Variante.

    Der AD-Container ist ja in der Konfiguration vorhanden.

    Was ich trotz sehr sehr sehr viel Lesens nicht genau ergründen konnte ist - Wenn Client und Server noch die alte URL abfragen wollen:

    - ein manueller URL-Check via Certutil funktioniert (die Liste als OK) angegeben wird

    - Der alte ldap-crl eintrag im CDP als Sperrlisten Verteilpunkt angegeben ist.

    was fehlt uns noch? Muss ich den alten CDP Distribution Point noch via "certutil -f -dspublish <CRLDATEI> CRL" im AD bekannt machen? Die URL scheint ja generell erreichbar zu sein. :-/

    Da verlässt mich aktuell mein Verständnis, was der Client falsch macht.

    Capi2-Log sagt auch nur der Server scheint offline zu sein - was ja fakt ist, aber die angegebene URL ist ja trotzdem abfragbar.

    Vermutlich ist es nur eine winzige Kleinigkeit. Die alten Zertifikate haben folgenden Eintrag:

    [1]Sperrlisten-Verteilungspunkt
         Name des Verteilungspunktes:
              Vollst. Name:
                   URL=ldap:///CN=<NameRootCA>,CN=<ShortnameAltServer>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=mkk,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint [...]

    Dies entspricht der manuellen Eintragung in der CDP erweiterung der Zertifizierungsstelle...

    Bin da etwas ratlos momentan... Dachte nach dem CRL-Client-Cache Timeout wäre der Spuk spätestens vorbei, allerdings wird der neue "alte" CDP eintrag auf der CA offenbar von den Clients nicht wahrgenommen.

    Besten Gruß

    Hecatonchires

    Freitag, 12. Juli 2019 06:50
  • Um auf den Kern Deiner Frage zurück zu kommen... "Ungern" würden wir einfach die "Lass alles automatisch neu ausstellen"-Karte ziehen.

    Sorry, aber von "automatisch" war nirgendwo die Rede.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 12. Juli 2019 06:55
  • Moin,

    Du musst mal die Berechtigungen auf dem Container im AD checken. Evtl. hat der neue Server kein Recht, dorthin zu schreiben, oder ihr habt irgendwas gänzlich verbogen. Im Zweifel eine Enterprise-CA auf einer Test-VM aufsetzen und einen A/B-Vergleich machen.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 12. Juli 2019 07:14
  • Stimmt ja xD - Wäre hier gelandet:
    "

    All the currently issued certificates contain Certificate Template Information extension by default. It contains the version of certificate template under which the certificate has been issued.

    Open the Certificate Templates console. When you right-click a certificate template in the console and select Reenroll all certificate holders, then version number of the certificate template increments its major part.

    Once a certificate autoenrollment client checks the list of certificate templates again (periodically every 12 hours), it reenrolls (it means no renewal, just a new enrollment) all currently existing certificates that have the same certificate template with a greater major version number than the version number the current certificate has been issued with.

    It does not depend on the issuing CA. Whichever issuing CA offers the certificate template, randomly, it will be asked to provide the new certificate with new keys."

    Also eher ein geplanter reenroll für alle Clients.

    Zumindest verstehe ich die Mechanik so...

    Aber danke für den Tipp... ich checke mal die Berechtigungen auf dem Container... vielleicht ist da wirklich was murks.

    Hab auch schon überlegt das ganze in einer VM-Testumgebung aufzubauen und abzubilden... allerdings weiß ich noch nicht, was mehr Zeit zieht... und auf der grünen Wiese macht man gerne alles richtiger... :(

    Freitag, 12. Juli 2019 07:43
  • Ich glaube ich habe das Problem gefunden... Eigentlich war alles gut:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/d7143ff5-e7d0-47d8-a15b-40ccfdaa680d/crl-distribution-points-for-old-ca-server?forum=winserversecurity

    Aber unsere eingestetze Variable für die CRLs war einfach falsch...

    Ich warte jetzt mal die Replikation ab und mit etwas Glück geht alles wieder :)

    @Evgenij - Vielen Dank für Deine Zeit

    Freitag, 12. Juli 2019 08:52
  • Ich glaube ich habe das Problem gefunden... Eigentlich war alles gut:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/d7143ff5-e7d0-47d8-a15b-40ccfdaa680d/crl-distribution-points-for-old-ca-server?forum=winserversecurity

    Aber unsere eingestetze Variable für die CRLs war einfach falsch...

    Ich warte jetzt mal die Replikation ab und mit etwas Glück geht alles wieder :)

    @Evgenij - Vielen Dank für Deine Zeit

    Hat leider auch nicht geklappt... ich denke wir lassen die alten Zertifikate einfach auslaufen und sind mit den neuen zurück im Spiel. Bekomme es einfach nicht gekittet...

    Einer der Hauptgründe das in der Form wieder zum fliegen zu bekommen war der Anspruch MSCEP in Betrieb zu nehmen. Leider hatten wir die Rolle vorher installiert, daher sind die ...-RA Zertifikate noch mit dem alten CDP Eintrag erstellt worden und die CRL wird halt nicht gefunden. Werde also SCEP auf einem anderen Server einrichten und die Rolle auf der CA entfernen.

    Freitag, 12. Juli 2019 15:12
  • Hi.

    Sind in das gleiche Problem gelaufen. 

    Lösung ist die neue CA dazu zu bringen die CRL in das alte AD Objekt zu publishen.

    Damit funktionieren die bereits ausgerollten Zertifikate weiter.

    Die entsprechende Einstellung kann in den CA Eigenschaften --> Extensions bearbeitet werden. Einen neuen CDP Eintrag erstellen für das AD Objekt der alten CA.

    Danach die neue CA eine CRL publishen lassen und damit sollte alles wieder funktionieren.

    LG

    rob

    • Bearbeitet rob3rix Dienstag, 3. Mai 2022 09:18
    Dienstag, 3. Mai 2022 09:04