none
Auto-Enrollment für Webserverzertifikate funktioniert nicht RRS feed

  • Frage

  • Hallo zusammen.

    Ich versuche, die Auto-Enrollment-Funktionalität für Webserver-Zertifikate zu realisieren. Nachgelagerte, andere Webserver als den IIS ("Automatischer Rebind erneuerter Zertifikate") würde ich dann per Eventgesteuertem Task realisieren, aber dazu komme ich bislang gar nicht.

    Der Der Domain Functional Level ist - wie alle drei Server (DC, CA und Testobjekt) - 2012R2.
    Leider bleiben die Eventlogs auf beiden Seiten leer, lediglich die Clientseite weist nach Ablauf des Zertifikats mit einer Fehlermeldung darauf hin, dass das Zertifikat abgelaufen ist.
    Das merkwürdigste daran ist, dass es ganz zu Beginn der Tests funktionierte - als ich das initiale Zertifikat noch über Microsofts veraltete und nicht mehr lange supportete Web-Oberfläche beantragt hatte. Die Beantragung über certlm.msc funktioniert auch fehlerfrei, nur die automatische Erneuerung funktioniert dann leider nicht - ohne dass ich einen Hinweis darauf finden kann, woran das liegt. Hat hier vielleicht jemand eine Idee, die mir weiterhelfen könnte?

    Vielen lieben Dank schon einmal!
    Donnerstag, 3. Januar 2019 09:34

Alle Antworten

  • Moin,

    Sanity Check - da das manuelle Enrollment funktioniert, bleiben nur zwei Punkte:

    • hat der Client Autoenrollment-Rechte auf der Webserver-Vorlage?
    • ist Autoenrollment in der Computer-Richtlinie aktiviert, die auf den Client wirkt?

    Rückfrage von mir: Wo kommt die Aussage her, dass das Web Enrollment nicht mehr lange supported wird? ("veraltet" trifft hier natürlich 100% zu ;-) ) In Server 2016 ist sie noch unverändert enthalten, somit gehe ich davon aus, dass sie noch mindestens 7 Jahre supported ist.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 3. Januar 2019 09:59
  • Hi Evgenij,

    die Info habe ich von einem Kollegen, dass es nicht weiter entwickelt werden würde von Microsoft. Klar, solange es Teil des Releases war gibts den ganz normalen 10-Jahre-Lifecycle. Aber bei 2019 weiß ich nicht, ob es noch dabei ist, haben wir noch nicht angetestet.

    Zu den Einstellungen: Leider kann ich hier keine Bilder verwenden oder Hyperlinks setzen.
    GPO:
    imgur.com/a/2aQr0f8
    Template:
    imgur.com/a/sRD4bIl

    Eine Idee, die ich noch habe, ist, dass irgendwelche Pflichtangaben fehlten bei der Zertifikatsanfrage. Welche sind denn zwingend auszufüllen? Habe dazu keine Infos im Netz gefunden.
    Donnerstag, 3. Januar 2019 11:37
  • Moin,

    wenn Du in der Vorlage schreibst, dass die Angaben im Request einzureichen sind, kann sie nicht für Autoenrollment verwendet werden. Da musst Du die Angaben aus dem Active Directory verwenden.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 3. Januar 2019 12:27
  • Das heißt ja aber im Umkehrschluss automatisch, dass eigene DNS-Aliase dann nicht per Auto-Enrollment abgebildet werden können? Der Gedanke war, dass vorhandene Zertifikate mit den vorhandenen Einstellungen erneuert werden, also auch mit den vorhandenen DNS-Aliasen als Alternative SANs. Sprich: Initiale Zertifikatsanfrage per certlm.msc, alle Verlängerungen hingegen funktionieren dann automatisch. Wenn Microsoft das gar nicht abdecken kann, muss ich mir wohl doch eine Powershell-Lösung zusammen basteln oO :(

    Donnerstag, 3. Januar 2019 12:35
  • Hmmm. So ganz falsch war der Gedanke laut Doku nicht. Ich teste das mal hier.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 3. Januar 2019 20:51
  • Ich bin gespannt. Im Übrigen hat mein Test, die Daten aus AD für das Zertifikat zu verwenden, ebenfalls nicht funktioniert, es wird einfach nicht automatisch erneuert. Laut gpresult kommt das GPO an und wird angewendet, laut Eventlogs hingegen gibt es gar keinen Versuch, das Zertifikat zu erneuern. Beim Erstellen des Zertifikats wähle ich gar explizit das Zertifikate-Template aus, also kann der Server auch darauf zugreifen - Gruppenmitgliedschaft in AD für die Berechtigung ist ja schließlich ebenfalls gegeben. Ich vermute, dass am Template selbst irgend ein Parameter nicht passt, aber ich finde nicht heraus, was dafür verantwortlich ist, dass es nicht funktioniert. Selbst ohne eigene DNS-Aliase. Kopiere mir nun das Webserver-Template erneut und fang nochmal bei 0 an, vielleicht bekomme ich es ja doch noch zum Laufen. Äußerst merkwürdiges Verhalten.
    Freitag, 4. Januar 2019 08:16
  • Moin,

    ich hatte leider nur eine 2008R2-Umgebung, wo ich das testen konnte. Hier hat es funktioniert, allerdings erst, nachdem das Zertifikat abgelaufen war. Der Client war allerdings die ganze zweite Hälfte der Gültigkeitsdauer ausgeschaltet. Aber die Namen hatten nichts mit dem Computernamen zu tun, somit ist Dein Vorhaben auf jeden Fall möglich und richtig.

    Bei so kurzfristigen Funktionstests muss man natürlich beachten, dass diese Autoenrollment-Vorgänge erst bei GPO Refresh getriggert werden und ab Server 2012 /Windows 8 auch zusätzlich beim Boot. Manuell triggern geht also mit

    gpupdate /force

    oder, wenn man das nicht machen kann oder möchte, mit

    certutil -pulse

    Und, for what it's worth: Die alten ASP-Seiten sind auch bei Server 2019 RTM unverändert vorhanden ;-)


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.


    Freitag, 4. Januar 2019 09:44
  • Habe nun eine neue Vorlage verwendet, allerdings wieder mit dem gleichen Ergebnis. Nun habe ich aber wenigstens das Wissen, dass es in der Theorie funktionieren sollte, auch wenn es bei mir nicht funktioniert. Das hilft auch schon einmal weiter, danke dir an dieser Stelle! Hast du irgendwelche bestimmte Parameter gesetzt gehabt? Auf Clientseite denke ich hast du die Kompatibilität auf Server 2008 R2 gesetzt gehabt?

    Im aktuellen Test habe ich mal das Rebind renewed certificates im IIS, den ich auf dem Testserver habe, deaktiviert und das Zertifikat mal nicht im IIS verwendet. Vielleicht gibt es ja an der Stelle Störpotenzial...
    Freitag, 4. Januar 2019 12:15
  • Genau, die Vorlage war 2008R2, ansonsten exakt wie auf Deinen Screenshots.

    Verstehe ich Dich richtig: Selbst wenn Du das Zertifikat komplett ablaufen lässt und dann einen certutil -pulse machst, wird es *nicht* erneuert? 


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 4. Januar 2019 12:18
  • Das hatte ich nicht getestet - aber den Rechner in der Zwischenzeit eigentlich neu gestartet gehabt. Nach dem Befehl wurde das abgelaufene Zertifikat nun erneuert. Das Zertifikat ist nun eine Stunde lang gültig, danach bin ich gespannt, ob Auto-Renewal nach einmaliger Ausführung funktioniert. Ich recherchiere in der Zwischenzeit einmal, was genau der Befehl macht, vielleicht hilft mir das bei der Fehleranalyse weiter.

    Vielen Dank dir an der Stelle einmal, dass du dir so viel Zeitaufwand mit meinem Problem machst!
    Freitag, 4. Januar 2019 13:40
  • Ok, Automatischer Renewal des Zertifikates funktionierte wieder nicht. Ich habe diesmal dann aber vor dem wieder händischen Befehl "certutil -pulse" noch das Zertifikat im IIS gesetzt und "Automatically rebind a renewed certificate" aktiviert. Nach dem "certutil -pulse" funktionierte dieser Teil wiederrum problemlos. Also wäre der workaround, einen Task zu erstellen, der einmal am Tag / in der Nacht gestartet wird und "certutil -pulse" ausführt. Warum mein Windows Server das nicht von alleine hinbekommt, ist mir allerdings nach wie vor ein Rätsel :(
    Freitag, 4. Januar 2019 14:49
  • Warum mein Windows Server das nicht von alleine hinbekommt, ist mir allerdings nach wie vor ein Rätsel :(

    Schau mal, wie das getriggert wird. Per Default gibt es dafür einen geplanten Task mit drei Triggern: Bei Start (und ab da alle 8 Stunden), bei Änderung des Tasks selbst und bei Event-ID, was einer erfolgreichen Anwendung der Group Policies entspricht. Sind diese Tasks oder einzelne Trigger deaktiviert oder gelöscht worden, findet das automatische Enrollment halt nicht statt.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 4. Januar 2019 21:31