Zertifikate auf Windows-Servern erneuern sich selbst: Autoenrollment per Gruppenrichtlinie

Manuell ausgestellte Serverzertifikate im Homelab laufen meistens genau dann ab, wenn man gerade an einer ganz anderen Baustelle arbeitet. Nachdem meine interne Windows-Zertifizierungsstelle stand, habe ich die fünf Windows-Server der Domäne example.lan auf Autoenrollment per Gruppenrichtlinie umgestellt, damit sich die Maschinen ihre Zertifikate selbst holen und sechs Wochen vor Ablauf erneuern. Der Weg dorthin führte über eine verschärfte Active-Directory-Quote, eine nachgebesserte Zertifikatvorlage für Remotedesktop, abgelehnte Anforderungen im Acht-Stunden-Takt auf den Domänencontrollern und ein verwaistes Computerkonto.

Der Unterbau: Root-CA und Windows-Sub-CA

Meine interne Public Key Infrastructure (PKI) ist zweistufig aufgebaut. An der Spitze steht eine Root-CA (RSA 4096 Bit, gültig bis Oktober 2046), die ich mit XCA angelegt habe. Ich brauche sie nur selten: wenn ich eine nachgeordnete Zertifizierungsstelle signiere oder einmal im Jahr die Root-Sperrliste erneuere.

Den laufenden Betrieb übernimmt die ausstellende Zertifizierungsstelle auf ca01.example.lan. Die virtuelle Maschine läuft auf Knoten 3 meines Proxmox-Clusters mit 2 vCPUs, 3 GB RAM, 60 GB Speicher und virtuellem TPM 2.0 unter Windows Server 2025 Datacenter (Build 26100.33438, nach einem In-Place-Upgrade von Server 2022 Evaluation). Als Enterprise-Subordinate-CA ist sie ins Active Directory eingebunden; ihr eigenes Zertifikat gilt zehn Jahre bis Oktober 2036 und hat die Pfadlängenbeschränkung 0, sodass sie selbst keine weiteren Sub-CAs unter sich ausstellen darf.

Das CA-Zertifikat und die Sperrliste (CRL) veröffentlicht ca01 sowohl im Active Directory per LDAP als auch per HTTP über einen lokalen IIS unter http://pki.example.lan/ (ein CNAME auf ca01 mit dem Verzeichnis C:\inetpub\pki). Die Sperrliste ist jeweils eine Woche gültig. Während die Linux-Hosts und Webdienste ihre Zertifikate über einen zentralen Systemd-Timer mit eigenem Dienstkonto beziehen, nutzen die Windows-Server der Domäne das bordeigene Autoenrollment.

Vorarbeit im Active Directory: MachineAccountQuota und Opt-in-Gruppe

Bevor ich die erste Zertifikatvorlage für Computerkonten freigeschaltet habe, war eine Standardeinstellung im Active Directory dran: das Attribut ms-DS-MachineAccountQuota. Ab Werk steht dieser Wert in einer Windows-Domäne auf 10. Das bedeutet, dass jeder normale Domänenbenutzer bis zu zehn eigene Computerkonten im Verzeichnis anlegen darf. Kombiniert man diese Vorgabe mit aktivem Autoenrollment für Domänencomputer, kann sich ein angemeldetes Konto ein Computerobjekt mit beliebigem Namen anlegen und dafür ein gültiges Serverzertifikat abrufen.

Ich habe ms-DS-MachineAccountQuota deshalb im Active Directory vorab von 10 auf 0 gesetzt. Als Rückfallplan für den Fall, dass ein bestehender Ablauf beim Domänenbeitritt streikt, war dokumentiert, den Wert wieder auf 10 zurückzusetzen.

Außerdem wollte ich das Autoenrollment nicht pauschal über die Gruppe Domänencomputer ausschütten. Stattdessen gibt es in meiner eigenen Organisations-OU eine Sicherheitsgruppe PKI-Server, in die ausschließlich die gewünschten Computerkonten per Opt-in aufgenommen werden. Für den Pilotbetrieb kam als einziges Mitglied zunächst ca01 selbst in diese Gruppe.

Die Zertifikatvorlage für Mitgliedsserver

Die mitgelieferte Standardvorlage WebServer eignet sich nicht für das automatische Ausrollen an Serverkonten, weil der Antragsteller darin den Zertifikatsnamen (Subject und Subject Alternative Name) frei im Antrag angeben darf. Wer diese Vorlage nutzen darf, kann sich ein Zertifikat für jeden beliebigen Hostnamen in der Domäne ausstellen lassen. Auf ca01 bleibt WebServer deshalb streng auf Domänen- und Organisations-Administratoren beschränkt.

Für die Windows-Mitgliedsserver habe ich eine eigene Vorlage Server-Auth auf Basis von Schema-Version 2 angelegt. Die Eckdaten der Vorlage sind eng gefasst:

• Antragstellername wird aus dem Active Directory gebildet (DNS-Name des Computerkontos im Feld Subject Alternative Name), keine manuelle Namenseingabe im Antrag.
• Schlüssellänge 2048 Bit, privater Schlüssel ist als nicht exportierbar markiert.
• Gültigkeitsdauer 2 Jahre, automatische Erneuerung 6 Wochen vor Ablauf.
• Berechtigungen Registrieren (Enroll) und Automatisch registrieren (Autoenroll) nur für die Sicherheitsgruppe PKI-Server (sowie Domänen-Admins).

Beim Veröffentlichen der Vorlage an der Issuing CA bin ich in eine typische Remote-Verwaltungsfalle getreten: Ich verwalte ca01 von meinem Linux-Verwaltungshost aus über WinRM (ohne SSH). Der Befehl certutil -setcatemplates +Server-Auth schlägt über eine einfache WinRM-Sitzung fehl, weil certutil vom CA-Server aus auf das Active Directory auf dem Domänencontroller zugreifen muss – ein klassischer Double-Hop, bei dem die Anmeldedaten ohne CredSSP oder Kerberos-Delegierung nicht weitergegeben werden. Direkt in einer lokalen Sitzung auf dem Server oder mit entsprechender Delegierung lässt sich die Vorlage veröffentlichen.

Gruppenrichtlinie, Pilotbetrieb und das RDP-Zertifikat

Für die Verteilung im Active Directory sorgt die Gruppenrichtlinie PKI-Autoenrollment, die auf Domänenebene verknüpft ist. Über den Sicherheitsfilter galt sie im ersten Schritt nur für die Gruppe PKI-Server. In der Richtlinie unter Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Richtlinien für öffentlichen Schlüssel ist der Zertifikatdienste-Client - Automatische Registrierung aktiviert.

Im selben Zug wollte ich erreichen, dass der Remotedesktopdienst (RDP) auf den Servern nicht mehr sein selbstsigniertes Zertifikat vorzeigt, sondern das von der Domänen-CA ausgestellte Zertifikat nutzt. Dazu hatte ich in der GPO zusätzlich unter Administrative Vorlagen > Windows-Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Sicherheit die Einstellung für die Serverauthentifizierungs-Zertifikatvorlage (ServerAuthenticationCertificateTemplate) auf Server-Auth gesetzt.

Beim Pilottest auf ca01 funktionierte die erste Hälfte sofort: Nach einem gpupdate /force lag wenige Sekunden später ein frisches Zertifikat der Vorlage Server-Auth (2048 Bit, nicht exportierbar) im lokalen Computerspeicher, und ich konnte das alte manuelle Zertifikat löschen. Die RDP-Bindung über die Gruppenrichtlinie griff mit meiner ersten Vorlagenversion allerdings nicht allein. In der ersten Fassung der Vorlage war unter den Anwendungsrichtlinien (Enhanced Key Usage, EKU) ausschließlich Serverauthentifizierung eingetragen.

Ich habe die Vorlage Server-Auth daraufhin überarbeitet (Revision 101), sodass sie neben Serverauthentifizierung auch Remotedesktopauthentifizierung enthält, und die Bindung auf den Servern über eine geplante Aufgabe RDP-Zertifikat abgesichert. Danach zog der Umzug auf die weiteren Server weiter: Der Dateiserver fs01 und der Medienserver sollten ihre Zertifikate ebenfalls über Server-Auth erhalten, während die beiden Domänencontroller dc01 und dc02 die Standardvorlage KerberosAuthentication (Gültigkeit ein Jahr) bekamen. Auf beiden DCs lief LDAPS nach dem automatischen Zertifikatsbezug mit der neuen Kette, sodass auch dort die alten manuellen Zertifikate weichen konnten.

Systemgruppe	Server im Homelab	Zertifikatvorlage	Gültigkeit / Erneuerung	Einsatzzweck
Mitgliedsserver (Gruppe PKI-Server)	ca01, fs01, medien01	Server-Auth (Schema 2, Rev. 101)	2 Jahre / 6 Wochen	Serverauthentifizierung, Remotedesktop (RDP)
Domänencontroller	dc01, dc02	KerberosAuthentication	1 Jahr / Vorlagenstandard	Kerberos, LDAPS, DC-Authentifizierung
Administratoren (manuell)	nach Bedarf	WebServer	manuell	Sonderfälle mit freiem SAN (nur Domänen-/Org-Admins)

Falle 1: Abgelehnte Anforderungen im Acht-Stunden-Takt auf den DCs

Zwei Tage nach dem Ausrollen meldete sich Checkmk auf dc02 beim Dienst Log Application mit zwei kritischen Fehlern und einer Warnung. Im Anwendungsprotokoll stand das Ereignis 6 der Quelle AutoEnrollment (ausgeführt vom Konto Lokales System) zusammen mit CertEnroll Ereignis 13 und dem Fehlercode 0x80094012:

Ereignis-ID: 6 (Quelle: Microsoft-Windows-CertificateServicesClient-AutoEnrollment)
Fehlercode:  0x80094012 (CERTSRV_E_TEMPLATE_DENIED)
Meldung:     Die Berechtigungen für die Zertifikatvorlage erlauben dem aktuellen
             Benutzer nicht, diesen Zertifikattyp anzufordern.

Ein Blick in die Datenbank der Zertifizierungsstelle auf ca01 unter „Fehlgeschlagene Anforderungen“ zeigte, was im Hintergrund ablief: Pünktlich alle acht Stunden – um 02:36, 10:36 und 18:36 Uhr – forderte dc02 per Autoenrollment ein Zertifikat der Vorlage Server-Auth an, und ca01 lehnte jeden Antrag mit CERTSRV_E_TEMPLATE_DENIED ab. Auf dc01 passierte zeitversetzt (unter anderem um 06:24 Uhr) genau dasselbe; die laufende Anforderungsnummer an der CA stieg bis zum 21. Oktober auf 153, ein großer Teil davon waren abgelehnte Anträge der Domänencontroller.

Auf den ersten Blick passte das nicht zusammen. Das eigentliche DC-Zertifikat aus der Vorlage KerberosAuthentication war auf beiden Domänencontrollern gültig, LDAPS antwortete fehlerfrei, und in den Vorlagenberechtigungen von Server-Auth stand ausschließlich die Gruppe PKI-Server. Weder dc01 noch dc02 waren Mitglied dieser Gruppe (ihr Token enthielt nur Domänencontroller). Normalerweise überspringt der Autoenrollment-Client alle Vorlagen, für die dem Computerkonto das Recht Automatisch registrieren fehlt.

Auch die erste Diagnose auf den DCs mit certutil -v -template und ein Abgleich des lokalen Vorlagen-Caches mit dem Active Directory zeigten keinen Unterschied. Es gab keine alten Einträge unter AutoEnrollment im Verzeichnis (ACRS) und keinen festhängenden Antrag im lokalen REQUEST-Zertifikatspeicher.

Die Spur führte zur Einstellung ServerAuthenticationCertificateTemplate für die Remotedesktopdienste in der Gruppenrichtlinie PKI-Autoenrollment. Sobald die GPO auch für die Domänencontroller galt, fordern die DCs offenbar alle acht Stunden genau diese Vorlage Server-Auth bei der CA an – ungeachtet der Tatsache, dass das DC-Computerkonto auf der Vorlage gar kein Enroll-Recht besaß. Die CA prüfte die ACL der Vorlage und wies den Antrag mit 0x80094012 ab.

Um die Fehlversuche abzustellen, lagen drei Optionen auf dem Tisch:

1. Der Gruppe Domänencontroller auf der Vorlage Server-Auth ebenfalls Registrieren und Automatisch registrieren einräumen (mit vorheriger SDDL-Sicherung der ACL für Set-Acl). Dann bekämen beide DCs ein zusätzliches Zertifikat für RDP, und die Ablehnungen würden sofort aufhören. Ein vorbereiteter Skriptlauf dafür brach bei der Ausführung an einer interaktiven Bestätigungsabfrage ab, weil stdin im Aufruf leer war (Returncode 1), sodass die Vorlagenrechte unangetastet blieben.
2. Die RDS-Vorlageneinstellung ServerAuthenticationCertificateTemplate aus der gemeinsamen GPO herausnehmen, damit die DCs nicht mehr gezwungen werden, die Mitgliedsserver-Vorlage anzufragen.
3. Das Ereignis 6 mit dem Fehler 0x80094012 in Checkmk ausblenden. Das habe ich verworfen, weil die CA dann im Hintergrund weiter dreimal täglich abgelehnte Anforderungen in ihre Datenbank schreibt.

Ich habe mich für den zweiten Weg entschieden und ServerAuthenticationCertificateTemplate aus der GPO entfernt. Nach einem gpupdate am 20. Oktober um 10:28 Uhr war der Registry-Wert auf den Domänencontrollern verschwunden.

Falle 2: Das verwaiste Computerkonto in der Sicherheitsgruppe

Während ich wegen des DC-Fehlers die Gruppenmitgliedschaften von PKI-Server und die Gruppenzugehörigkeiten der Computerkonten (tokenGroups) im Active Directory per WinRM geprüft habe, fiel mir eine zweite Ungereimtheit auf. In der Gruppe sollten drei Server stehen: ca01, fs01 und der Medienserver medien01. In der Mitgliederliste stand neben ca01 und fs01 aber das Konto medien01-alt.

Aus einer früheren Installation des Medienservers existierte im Active Directory noch das alte Computerkonto mit dem Suffix -alt. In der Gruppe PKI-Server stand dieses Altkonto, nicht das Computerkonto der laufenden Maschine medien01. Die Folge war simpel: Das tote Konto hatte zwar alle Rechte zum automatischen Zertifikatsabruf, existierte aber als Server nicht mehr. Der echte Server medien01 lief dagegen ohne Mitgliedschaft in PKI-Server, fiel durch den Sicherheitsfilter der GPO und bekam überhaupt kein Zertifikat von der CA.

Die Korrektur ist freigegeben, aber zum Zeitpunkt dieses Textes noch nicht ausgeführt. Sie braucht keinen Neustart: Auf einem Domänencontroller wird das aktive Computerkonto medien01 in die Gruppe PKI-Server aufgenommen und medien01-alt entfernt. Das Löschen des Altkontos aus dem Active Directory ist ein eigener, späterer Schritt. Als Rückfallplan beim Tausch ist vorgesehen, die Mitgliedschaften bei Bedarf wieder zurückzutauschen. Sobald die AD-Replikation zwischen den Domänencontrollern durch ist, reicht am Medienserver ein gpupdate mit anschließendem Prüfen des Zertifikatsabrufs.

Prüfliste für die Diagnose am Server

Wenn ein Windows-Server trotz eingerichteter GPO kein Zertifikat bezieht oder die CA Anforderungen mit 0x80094012 ablehnt, gehe ich diese Prüfpunkte durch:

# 1. Welche Gruppenrichtlinien kommen beim Computerkonto an?
gpresult /r

# 2. Welche Vorlagen und Berechtigungen sieht der Client (AD vs. Cache)?
certutil -v -template

# 3. Autoenrollment-Lauf manuell anstoßen (z. B. mit aktivem CAPI2-Protokoll)
certutil -pulse

Ergänzend lohnt sich bei abgelehnten Anforderungen der Blick auf tokenGroups des Computerkontos im Active Directory, auf offene Anträge im lokalen REQUEST-Speicher sowie auf alte Einträge unter AutoEnrollment (ACRS) im AD. Reichen die Standardmeldungen im Anwendungsprotokoll (AutoEnrollment Ereignis 6 und CertEnroll Ereignis 13) nicht aus, lässt sich für einen gezielten Lauf mit certutil -pulse kurzzeitig das CAPI2-Diagnoseprotokoll in der Ereignisanzeige einschalten.

Was noch offen ist

Auf den beiden Domänencontrollern dc01 und dc02 ist die Geschichte nach dem Entfernen von ServerAuthenticationCertificateTemplate aus der Gruppenrichtlinie noch nicht ganz ausgestanden: Obwohl der Registry-Wert seit dem gpupdate am 20. Oktober weg ist, liefen am 21. Oktober um 06:24 Uhr auf dc01 und um 10:36 Uhr auf dc02 weiter Anforderungen für Server-Auth bei der CA auf (Anforderung 153, wieder abgewiesen mit 0x80094012). Mein nächster Prüfschritt dort gilt dem Dienst SessionEnv (Remotedesktopkonfiguration), der den alten Vorlagenwert möglicherweise bis zu einem Dienstneustart im Speicher behält, sowie eventuell archivierten Anforderungen im lokalen Zertifikatspeicher. Parallel dazu stehen auf ca01 noch die regelmäßige Sicherung der Sub-CA-Datenbank mit certutil -backup samt Test-Restore und ein Checkmk-Check für die Ablaufdaten der Zertifikate und Sperrlisten auf der Liste.