winary
Goto Top

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:

kaputteszertifikat

kaputteszertifikat2


Das Gegenstück dazu in der CA:

zertifikats-pendant-der-ca


Danke im Voraus und Grüße

Winary

Content-ID: 657744

Url: https://administrator.de/contentid/657744

Ausgedruckt am: 25.11.2024 um 05:11 Uhr

Dani
Dani 01.03.2021 um 11:48:41 Uhr
Goto Top
Moin,
Domänenmitglied
Meinst du damit Benutzer- und/oder Computerkonten?
Um welche Art von Zertifikat handelt es sich?


Gruß,
Dani
Winary
Winary 01.03.2021 um 11:56:22 Uhr
Goto Top
Hier ein Beispiel gerade von einer neuen Vorlage für ein Webserver-Zertifikat. Dieses kam am Client an:

Vorwiegend nutze ich die Genehmigung der CA nur zur Ausstellung von angepassten Computerzertifikaten wie Webserver (IIS) und RDP-Zertifikaten von Remotedesktop-Sitzungshosts.
C.R.S.
C.R.S. 01.03.2021 aktualisiert um 11:57:52 Uhr
Goto Top
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
Winary
Winary 01.03.2021 aktualisiert um 12:15:43 Uhr
Goto Top
Zitat von @c.r.s.:
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).

Das macht natürlich Sinn, Danke für die Aufklärung.

In welchem Zeitraum/Intervall werden denn die Antwortzertifikate von der CA abgefragt?
Und mit welchem Powershell-Befehl lässt sich das Zertifikat möglichst sofort von der CA abrufen?

Was ich auch nicht verstehe, certutil -pulse betrifft ja offenbar nur automatisch zu registrierende Zertifikate, aber Autoenrollment (mit GPO) habe ich außer für reguläre Benutzer- und Computerzertifikate nie im Einsatz.
C.R.S.
Lösung C.R.S. 01.03.2021 aktualisiert um 12:30:03 Uhr
Goto Top
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
}
C.R.S.
C.R.S. 01.03.2021 aktualisiert um 12:54:31 Uhr
Goto Top
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.
Winary
Winary 01.03.2021 aktualisiert um 13:07:02 Uhr
Goto Top
Zitat von @c.r.s.:
Das Intervall müsste ich auch recherchieren, ich denke so 2 Stunden.

Also, nach 2,5h hat sich nichts getan. Dann wird es wohl länger sein.

Certutil -pulse betrifft nicht nur Autoenrollment.

Als ich das ausgeführt habe, ist auch nichts passiert. Oder ich war zu ungeduldig.

> $csrs = Get-ChildItem Cert:\LocalMachine\REQUEST\
> foreach ($csr in $csrs){
>     Get-Certificate -Request $csr
> }
> 

Danke, das hat geklappt. Das "fehlerhafte" Zertifikat, bzw. der reine Request ist aus dem Ordner Zertifikatregistrierungsanforderungen verschwunden und unter eigene Zertifikate aufgetaucht. Die Gültigkeit mit zwei Jahren stimmt nun auch und die Fingerabdrücke auf beiden Seiten sind auch identisch.

Ich hätte aber schwören können, dass ich früher auch schon Zertifikate ausgestellt bekommen habe, die nach der Genehmigung durch die CA völlig andere Eigenschaften und Gültigkeiten hatten. Das war glaube ich wenn ich Webserver-Zertifikate (nicht IIS) ausstellen wollte, deren Informationen aus einer CSR-Datei genommen werden sollten und über den Web-Registrierungsdienst angefordert wurden. Wenn ich von dort aus dann den CSR auf der CA genehmigt habe, dann hat das Zertifikat, dass ich danach von der http://.../cersrv/ -Seite herunterladen konnte, zwar den richtigen Namen, aber der Fingerabdruck und die Gültigkeit stimmten nicht überein. Die eingetragenen Subject Alternate Names (SAN) waren auch nicht enthalten.

Was kann man in diesem Fall tun?