ADCS - Zertifikat unterschiedlich oder kaputt wenn es von CA erst genehmigt werden muss
Hallo in die Runde,
ich habe nun schon öfters das Problem gehabt, dass wenn ich von einem Domänenmitglied von der CA (ADCS Windows Server 2016, zweistufig) ein Zertifikat ohne Genehmigung anfordere, dann wird dieses ganz normal anhand der ausgewählten Vorlage ausgestellt. Das Zertifikat in der CA und das Zertifikat am Client sind identisch.
Führe ich dasselbe Szenario aus, wenn in der Vorlage der Haken bei "Genehmigung von Zertifikatverwaltung der Zertifizierungsstelle" gesetzt ist, dann wird das Zertifikat zwar ausgestellt, wenn ich das Zertifikat in den ausstehenden Anforderungen ausstelle, aber das Zertifikat, das am Client ankommt und im Speicher für Zertifikatregistrierungsanforderungen liegt, ist kaputt oder in einer ganz anderen Umgebung statt zwei Jahren Gültigkeit (in der Vorlage, z.B. Webserver, so festgelegt) nur ein Jahr Gültigkeit hat.
Mehr noch, der Fingerabdruck in beiden Szenarien ist immer unterschiedlich und gewisse Zertifikatskomponenten fehlen im Zertifikat, das am Client ankommt.
Hat damit schon jemand Erfahrung? Bisher muss ich mir behelfen, dass ich vor dem Ausstellen den Genehmigungshaken entferne und danach wieder setze.
Das ist aber nicht im Sinne des Erfinders schätze ich. Gibt es irgendeine Stellschraube, an der gedreht werden muss oder ist das ein Bug? Ich habe denselben Effekt auch schon bei Server 2012 (R2) erlebt.
Hier ein Beispiel gerade von einer neuen Vorlage für ein Webserver-Zertifikat. Dieses kam am Client an:
Das Gegenstück dazu in der CA:
Danke im Voraus und Grüße
Winary
ich habe nun schon öfters das Problem gehabt, dass wenn ich von einem Domänenmitglied von der CA (ADCS Windows Server 2016, zweistufig) ein Zertifikat ohne Genehmigung anfordere, dann wird dieses ganz normal anhand der ausgewählten Vorlage ausgestellt. Das Zertifikat in der CA und das Zertifikat am Client sind identisch.
Führe ich dasselbe Szenario aus, wenn in der Vorlage der Haken bei "Genehmigung von Zertifikatverwaltung der Zertifizierungsstelle" gesetzt ist, dann wird das Zertifikat zwar ausgestellt, wenn ich das Zertifikat in den ausstehenden Anforderungen ausstelle, aber das Zertifikat, das am Client ankommt und im Speicher für Zertifikatregistrierungsanforderungen liegt, ist kaputt oder in einer ganz anderen Umgebung statt zwei Jahren Gültigkeit (in der Vorlage, z.B. Webserver, so festgelegt) nur ein Jahr Gültigkeit hat.
Mehr noch, der Fingerabdruck in beiden Szenarien ist immer unterschiedlich und gewisse Zertifikatskomponenten fehlen im Zertifikat, das am Client ankommt.
Hat damit schon jemand Erfahrung? Bisher muss ich mir behelfen, dass ich vor dem Ausstellen den Genehmigungshaken entferne und danach wieder setze.
Das ist aber nicht im Sinne des Erfinders schätze ich. Gibt es irgendeine Stellschraube, an der gedreht werden muss oder ist das ein Bug? Ich habe denselben Effekt auch schon bei Server 2012 (R2) erlebt.
Hier ein Beispiel gerade von einer neuen Vorlage für ein Webserver-Zertifikat. Dieses kam am Client an:
Das Gegenstück dazu in der CA:
Danke im Voraus und Grüße
Winary
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 657744
Url: https://administrator.de/contentid/657744
Ausgedruckt am: 25.11.2024 um 05:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
das ist ein Missverständnis. Unter Zertifikatsanforderungen liegt nie das angeforderte Zertifikat, sondern der Request bzw. ein Platzhalter mit Metadaten zu Request und dem privaten Schlüssel. Das ist die Situation, wenn der Client das ausgestellte Zertifikat noch nicht abgerufen hat (certutil -pulse).
Bei ADCS auf Server 2019 habe ich allerdings erstmals beobachtet, dass certutil -pulse und der automatische Refresh das Zertifikat nicht abrufen, sondern ich das per PowerShell machen muss. Was nicht heißt, dass das spezifisch für 2019 wäre oder nicht an etwas anderem liegen könnte. Aber m.E. habe ich die ADCS aufgesetzt wie immer.
Beste Grüße
Richard
das ist ein Missverständnis. Unter Zertifikatsanforderungen liegt nie das angeforderte Zertifikat, sondern der Request bzw. ein Platzhalter mit Metadaten zu Request und dem privaten Schlüssel. Das ist die Situation, wenn der Client das ausgestellte Zertifikat noch nicht abgerufen hat (certutil -pulse).
Bei ADCS auf Server 2019 habe ich allerdings erstmals beobachtet, dass certutil -pulse und der automatische Refresh das Zertifikat nicht abrufen, sondern ich das per PowerShell machen muss. Was nicht heißt, dass das spezifisch für 2019 wäre oder nicht an etwas anderem liegen könnte. Aber m.E. habe ich die ADCS aufgesetzt wie immer.
Beste Grüße
Richard
Das Intervall müsste ich auch recherchieren, ich denke so 2 Stunden. Certutil -pulse betrifft nicht nur Autoenrollment. Wenn ich in einer 2016er-Domain Zertifikate manuell anfordere und nach der Genehmigung nicht warten will, mache ich das regelmäßig. Funktioniert nur nicht in einer anderen Domain-/ADCS-Infrastruktur mit 2019. Mit PS:
$csrs = Get-ChildItem Cert:\LocalMachine\REQUEST\
foreach ($csr in $csrs){
Get-Certificate -Request $csr
}
Wobei Du mich jetzt auf die Idee bringst, dass ich in der 2016er-Umgebung auch Auto-Enrollment nutze, in der 2019er noch nicht. Hm, aber die Auto-Enrollment GPOs sind ja gerade nicht aktiv auf dem Rechner, mit dem ich manuell anfordere und abrufe.
Edit: Nein, Auto-Enrollment ist doch schon in beiden Umgebungen aktiv.
Edit: Nein, Auto-Enrollment ist doch schon in beiden Umgebungen aktiv.