Da ich noch keine Fundstelle zu den folgenden Fehlercodes im Web finden konnte, will ich das hiermit nachholen und das damit verbundene Problem kurz darstellen.
Symptom
Beim versuchten Start der AD Certificate Services stürzt der Dienst gleich wieder ab. Dabei erscheint die Fehlermeldung
The process terminated unexpectedly. 0x42b (WIN32: 1067 ERROR_PROCESS_ABORTED)
Im Application Event-Log findet sich dazu keine Meldung unter der Quelle CertificationAuthority, dafür aber zwei Einträge unter der Quelle Application Error mit der Event-ID 1000 und dem Exception Code 0xc0000005 bzw. 0xc000041d.
Die Ursache
Die Active Directory Certificate Services reagieren sehr empfindlich auf unbekannte oder doppelte Einträge im Multi-String Registry-Wert
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA-Name>\SubjectTemplate
Dort wird vorgegeben, welche Namens-Elemente (Relative Distinguished Names, RDN) in welcher Reihenfolge im Subject-Namen von ausgestellten Zertifikaten vorkommen dürfen.
Eigentlich sollte bei fehlerhaften Einträgen im SubjectTemplate die CertificationAuthority einen aussagekräftigen Fehler mit Event-ID 19 ins Event-Log schreiben und sich kontrollliert beenden. In der Praxis stürzt certsrv.exe aber ab, wenn dort ein unbekannter oder doppelter Eintrag enthalten ist.
Wer das testen will, kann mit
certutil -setreg ca\subjecttemplate +foobar
dafür sorgen, dass seine CA beim nächsten Start mit den oben beschriebenen Meldungen abstürzt.
Die Lösung ist, mit RegEdit oder certutil -setreg den fehlerhaften oder doppelten Eintrag zu bereinigen bzw. zu entfernen. Dann startet die CA wieder wie gewohnt.
Wie kann es dazu kommen?
In zwei Szenarien habe ich es in der Praxis erlebt, dass dieser Fall unbeabsichtigt auftritt.
Das erste ist die Installation eines Network Device Enrollment Service (NDES) mit dem Microsoft-Installationsassistenten. Dabei werden der SubjectTemplate der CA, die den NDES bedient, die drei Werte DeviceSerialNumber, UnstructuredName und UnstructuredAddress hinzugefügt. Ganz gleich, ob diese bereits vorhanden sind oder nicht. Wer also einen dieser Werte schon vor der NDES-Installation im SubjectTemplate stehen hat, kommt wegen des doppelten Eintrags in den Genuss des Problems.
Das zweite Szenario ist gar nicht so leicht zu erkennen. Wenn man per Copy&Paste in RegEdit einen oder mehrere RDN-Namen zur SubjectTemplate hinzufügt, sollte man darauf achten, aus welcher Quelle sie kopiert werden. Ist die Copy-Vorlage beispielsweise ein Microsoft-Teams-Chat, kann es passieren, dass am Anfang der Zeile ein unsichtbares UTF8-Zeichen, die Byte Order Mark (BOM - das erklärt den Titel dieses kleinen Blogbeitrags) mitkopiert wird. Dieses zusätzliche Zeichen sorgt dann dafür, dass der Eintrag nicht als korrekt erkannt wird und zum Absturz führt, ist aber in der RegEdit-Ansicht nicht zu sehen.