Wer kennt sie nicht, die Irren der Microsoft Active Directory Certificate Services (ADCS). In diesem finden sich allerlei Probleme und Stolperfallen.
Ein Beispiel: Der Network Device Enrollment Service (NDES), welcher genutzt wird um Umsystemen die Ausstellung von Zertifikaten zu ermöglichen (Bsp. MDM-Systeme), verwendet zwei Zertifikate. Diese werden allerdings nicht automatisch verlängert, daher lohnt es sich, diese in einem entsprechenden Monitoring zu überwachen. Sind die Zertifikate kurz vor dem Ablauf, kann die Erneuerung recht problemlos durchgeführt werden.
Das CEP Encryption kann dabei einfach renewed werden. Das Exchange Enrollment Agent Zertifikat ist dabei schon etwas schwieriger. Da es sich eigentlich um ein Zertifikat vom Typ User handelt, welches als Computerzertifikat verwaltet wird, kann es nicht einfach neu angefordert werden. Das vorgehen hierzu wird von Microsoft in einem entsprechenden Artikel beschrieben:
Renewal of Enrollment Agent certificate fails – Windows Server | Microsoft Docs
Wichtig ist dabei, dass das Zertifikat noch nicht abgelaufen ist, da der Request vom alten Zertifikat signiert wird und sonst als ungültig abgewiesen wird. Was aber, wenn die Zertifikate schon abgelaufen sind und das vorgehen so nicht mehr funktioniert?
Für das CEP Encryption kann einfach eine neue Anfrage über die Zertifikatskonsole gestellt werden. Für das Exchange Enrollment Agent Zertifikat muss dagegen eine entsprechende Konfigurationsdatei erstellt und darüber das Zertifikat komplett neu angefordert werden (im Gegensatz dazu referenziert die Konfiguration im Microsoft Artikel auf das alte, bestehende Zertifikat). Eine ausführliche Anleitung dazu findet sich im nachfolgenden Link unter dem Punkt Renew expired Enrollment agent certificate:
How to renew NDES service certificates for usage with Microsoft Intune – MSEndpointMgr
Nach dem iisreset sollte der Dienst wieder verfügbar sein. Sind beide Zertifikate erneuert und der Dienst meldet trotzdem noch einen internen Serverfehler (500), fehlen vermutlich noch die Leserechte des Application Pool auf die neuen privaten Schlüssel. Mögliche Ursachen finden sich dazu in folgendem Artikel:
Das entsprechende Powershell Skript, um die privaten Schlüssel wieder lesbar zu machen, gibt es hier:
ADCS-Labor/NDESAppPoolKeyPermissions.ps1 at master · Sleepw4lker/ADCS-Labor · GitHub