9
Windows CA - gesperrte Zertifikate - Dauer bis Client das mitbekommt
Hi,
wie der Titel schon aussagt: Es geht um gesperrte Zertifikate in eine Windows Umgebung mit Windows Zertifizierungsstelle
Setup
Zustand
Das Zertifikat
Die Sperrliste
Wenn ich am Client die MMC "Zertifikate" öffne und in den Speicher des Computers schaue, dann wird dort das o.g. Zertifikat nach wie vor als gültig angezeigt. Ist das normal?
Der Client wurde schon mehrmals durchgestartet und auch "gpupdate /force" ausgeführt.
Die Sperrung des Zertifikats ist jetzt vor 22 h erfolgt.
Wie lange dauert es, bis ein Computer ein gesperrtes Zertifikat als solches erkennt?
Wo kann man sehen, mit welcher Sperrliste der Computer z.Z. arbeitet? (lokale Kopie im Cache?)
E.
wie der Titel schon aussagt: Es geht um gesperrte Zertifikate in eine Windows Umgebung mit Windows Zertifizierungsstelle
Setup
- Windows Server 2008 R2 Enterprise Server mit Zertifizierungstelle
- Zertifizierungstelle ist die einzige, also Root + ausstellende Stelle.
- CA ist AD-integriert
- Client mit Windows 10 Prof 1806
Zustand
- Client hat (bisher) gültiges Zertifikat von Standardvorlage "Computer"
- Dieses Zertifikat wurde an der CA gesperrt
- die Sperrliste wurde neu veröffenlicht (im AD)
- Client meldet das Zertifikat immer noch als gültig
Das Zertifikat
- wurde in 11/17 erstellt und in den lokalen Zertifikatspeicher des Clients (Local Machine) gespeichert.
- gilt bis 11/18 (Ablaufdatum)
- wurde gestern Nachmittag manuell an der CA gesperrt
Die Sperrliste
- wurde gestern nach dem Sperren des o.g. Zertikats an der CA neu veröffentlicht
- das zugehörige AD-Objekt in der Configuration Partition wurde aktualisiert ("whenChanged" überprüft)
- kann vom Client mit CERTUTIL als Datei heruntergeladen werden
- enthält die Seriennummer des o.g. Zertifikats (heruntergeladene Datei mit Hex-Editor überprüft)
Wenn ich am Client die MMC "Zertifikate" öffne und in den Speicher des Computers schaue, dann wird dort das o.g. Zertifikat nach wie vor als gültig angezeigt. Ist das normal?
Der Client wurde schon mehrmals durchgestartet und auch "gpupdate /force" ausgeführt.
Die Sperrung des Zertifikats ist jetzt vor 22 h erfolgt.
Wie lange dauert es, bis ein Computer ein gesperrtes Zertifikat als solches erkennt?
Wo kann man sehen, mit welcher Sperrliste der Computer z.Z. arbeitet? (lokale Kopie im Cache?)
E.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 379885
Url: https://administrator.de/contentid/379885
Ausgedruckt am: 19.11.2024 um 07:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
sind im Zertifikat auch die Informationen zur Sperrliste enthalten?
Grüße
lcer
sind im Zertifikat auch die Informationen zur Sperrliste enthalten?
Grüße
lcer
Ja. Da steht sowas drin (verfremdet)
Edit:
Das ist auch das o.g. AD-Objekt, welches ich überprüft habe.
[1]Sperrlisten-Verteilungspunkt
Name des Verteilungspunktes:
Vollst. Name:
URL=ldap:///CN=XXXXXXCA01,CN=XXXXXXCA01,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=DOMAIN,DC=TLD?certificateRevocationList?base?objectClass=cRLDistributionPoint (ldap:///CN=JXXXXXXCA01,CN=XXXXXXCA01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DOMAIN,DC=TLD?certificateRevocationList?base?objectClass=cRLDistributionPoint)Edit:
Das ist auch das o.g. AD-Objekt, welches ich überprüft habe.
Siehe:
https://www.msxfaq.de/signcrypt/crl.htm#crl_cache_auf_dem_client
Um einen User bei z.B. bei Abhanden kommen eines Gerätes zuverlässig auszusperren sollte man immer erst einmal das zugehörige Konto deaktivieren. Der Grund: Auch andere Server können noch veraltete Sperrlisten und Token-Caches nutzen und das Zertifikat weiterhin als gültig annehmen. Sperrlisten für solche Szenarien sollte man ebenfalls mit kurzen Intervallen und Ablaufdaten versehen.
Zusätzlich gilt es einen weiteren Cache zu beachten (TLS Handle Expiry Time) wenn man die Zertifikate im Zusammenhang mit dem NPS nutzt:
Manage Certificates Used with NPS
Grüße Uwe
https://www.msxfaq.de/signcrypt/crl.htm#crl_cache_auf_dem_client
Wie lange dauert es, bis ein Computer ein gesperrtes Zertifikat als solches erkennt?
Bis er die CRL nach dem Datum das in der Sperrliste steht, aktualisiert.Wo kann man sehen, mit welcher Sperrliste der Computer z.Z. arbeitet? (lokale Kopie im Cache?)
certutil -URLcache crl
certutil -URLcache ocsp
Um einen User bei z.B. bei Abhanden kommen eines Gerätes zuverlässig auszusperren sollte man immer erst einmal das zugehörige Konto deaktivieren. Der Grund: Auch andere Server können noch veraltete Sperrlisten und Token-Caches nutzen und das Zertifikat weiterhin als gültig annehmen. Sperrlisten für solche Szenarien sollte man ebenfalls mit kurzen Intervallen und Ablaufdaten versehen.
Zusätzlich gilt es einen weiteren Cache zu beachten (TLS Handle Expiry Time) wenn man die Zertifikate im Zusammenhang mit dem NPS nutzt:
Manage Certificates Used with NPS
Grüße Uwe
1
Hallo Uwe,
erstmal: Danke.
Bei mir geht es erstmal nur um einen Test.
Wir wollen eine CA ablösen, von welcher noch Zertifikate im Umlauf sind, welche bis 2022 gelten. Wir haben zwar schon die Vorlagen von der CA entfernt, sodass diese keine neuen Zertifikate mehr verteilen kann, aber wir würden diese gerne komplett abschalten.
Ich dachte mir, wenn ich die ausgestellten Zertifikate sperre, dann würden die Clients das mitbekommen und sich bei Bedarf ein neues Zertifikat von der neuen Zertifizierungsstelle holen.
Ja, danke, das ist sehr gut zu wissen.
Wenn ich das betreffende Zertifikat exportiere und dann damit überprüfe, dann kommt für "Basissperrliste" und "Deltasperrliste" ein "Überprüft". Die dort genannte URL ist dann auch genau jene, welche ich oben schon gepostet habe.
erstmal: Danke.
Um einen User bei z.B. bei Abhanden kommen eines Gerätes zuverlässig auszusperren sollte man immer erst einmal das zugehörige Konto deaktivieren. Der Grund: Auch andere Server können noch veraltete Sperrlisten und Token-Caches nutzen und das Zertifikat weiterhin als gültig annehmen. Sperrlisten für solche Szenarien sollte man ebenfalls mit kurzen Intervallen und Ablaufdaten versehen.
Das ist klar.Bei mir geht es erstmal nur um einen Test.
Wir wollen eine CA ablösen, von welcher noch Zertifikate im Umlauf sind, welche bis 2022 gelten. Wir haben zwar schon die Vorlagen von der CA entfernt, sodass diese keine neuen Zertifikate mehr verteilen kann, aber wir würden diese gerne komplett abschalten.
Ich dachte mir, wenn ich die ausgestellten Zertifikate sperre, dann würden die Clients das mitbekommen und sich bei Bedarf ein neues Zertifikat von der neuen Zertifizierungsstelle holen.
Ja, danke, das ist sehr gut zu wissen.
Wenn ich das betreffende Zertifikat exportiere und dann damit überprüfe, dann kommt für "Basissperrliste" und "Deltasperrliste" ein "Überprüft". Die dort genannte URL ist dann auch genau jene, welche ich oben schon gepostet habe.
certutil -URLcache crl
certutil -URLcache ocsp
Da liefert er mir nichts zur internen CA.certutil -URLcache ocsp
C:\Windows\system32>certutil -URL http://test
CertUtil: -URL-Befehl wurde erfolgreich ausgeführt.
C:\Windows\system32>certutil -URLcache crl
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab
WinHttp-Cacheeinträge: 1
CertUtil: -URLCache-Befehl wurde erfolgreich ausgeführt.
C:\Windows\system32>certutil -URLcache ocsp
http://ocsp.omniroot.com/baltimoreroot/MEUwQzBB..........7RVZ7LBduom%2FnYB45.....MIJHWMys%2BghUNoZ........BAcnonY%3D
http://ocsp.digicert.com/MFEw.......0V27RVZ7LBduom%2FnYB4......IJHWMys%2BghUNo......SRETRSlgpHeuVI%3D
http://ocsp.digicert.com/MFEwTzB..........gUABBTBL0V27RVZ7LBduom%2FnYB45.......Mys%2BghUNoZ7O......Tf7jUSfg%2BhWk%3D
http://ocsp.int-x3.letsencrypt.org/MFMw.......ABBR%2B5mrncpqz%2FPiiIG.....brm0Tm3pkVl7%2FOo7K......Nll1QQ%3D%3D
http://isrg.trustid.ocsp.identrust.com/MFEwTzBN........rb4UuQdf%2FEFWC.....C4Xspwg%3D
WinHttp-Cacheeinträge: 5
**** OFFLINE ****
CertUtil: -URLCache-Befehl wurde erfolgreich ausgeführt.
Update:
habe jetzt mit
direkt die CRL angesprochen. Da meldet er mir für beide Listen "OK". Anschließend hat er mir diese auch bei
angezeigt.
Es ändert aber nichts daran, das er sein eigenes Zertifikat nach wie vor als gültig anzeigt ...
habe jetzt mit
certutil -URL ldap:///CN=JXXXXXXCA01,CN=XXXXXXCA01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DOMAIN,DC=TLD?certificateRevocationList?base?objectClass=cRLDistributionPointcertutil -URLcache crl Es ändert aber nichts daran, das er sein eigenes Zertifikat nach wie vor als gültig anzeigt ...
Zitat von @emeriks:
Es ändert aber nichts daran, das er sein eigenes Zertifikat nach wie vor als gültig anzeigt ...
Daran wird sich in der MMC auch nichts ändern da kannst du kloppen und hämmern wo du willst, denn sie ist dumm und checkt die Zertifikate selbst nicht gegen die CRLs Es ändert aber nichts daran, das er sein eigenes Zertifikat nach wie vor als gültig anzeigt ...
.Certutil.exe is the command-line tool to verify certificates and CRLs. To get reliable verification results, you must use certutil.exe because the Certificate MMC Snap-In does not verify the CRL of certificates. A certificate might be wrongly shown in the MMC snap-in as valid but once you verify it with certutil.exe you will see that the certificate is actually invalid.
certutil -f –urlfetch -verify [FilenameOfCertificate]
Danke Uwe, das war's!
liefert
certutil -f -urlfetch -verify d:\temp\test.cerliefert
........
Das Zertifikat wurde gesperrt. 0x80092010 (-2146885616 CRYPT_E_REVOKED)
------------------------------------
Das Zertifikat ist GESPERRT.
Untergeordnetes Zertifikat wurde gesperrt (Grund=4)
Hi zusammen,
da das Problem dieses Threads sehr ähnlich zu meinem ist, dachte ich mir, ich hänge mich hier mal an.
Meine Ausgangssituation ist nahezu die gleiche, mit dem Unterschied, dass ich den NPS und die CA auf jeweils einem Server 2016 betreibe.
Die Zertifikatsvorlage ist ein Klon der "Computer"-Vorlage, die per Auto-Enrollment GPO dem Client zugewiesen wird.
Um das Verhalten zu testen habe ich nun das Zertifikat an der CA gesperrt und die CRL veröffentlicht. Außerdem habe ich auf allen beteiligten den CRL-Cache gelöscht.
Ich bin schonmal so weit, dass ich per "certutil -verify [cer-file]" auf dem Client sehe, dass das Zertifikat gesperrt wurde.
Ebenfalls habe ich (wie in Colinardos Link beschrieben)auf dem NPS den Registry-Key für die Deaktivierung des TLS-Handle Caches gesetzt:
Alternativ dazu habe ich auch mal 14 Stunden abgewartet. Das Problem war allerdings immer noch: die Authentifizierung per 802.1X des Clients wurde - trotz dem gesperrten Zertifikat - zu keiner Zeit vom NPS abgewiesen. Wenn ich das Computerkonto deaktiviere oder aus der (auf dem NPS berechtigen) Gruppe werfe, weist der NPS die Anfrage erwartungsgemäß ab.
Der Sinn sollte aber doch sein, dass (früher oder später) auch bei einem gesperrten Zertifikat kein Zugriff mehr möglich ist.
Wo könnte hier das Problem liegen?
Gruß, JD
da das Problem dieses Threads sehr ähnlich zu meinem ist, dachte ich mir, ich hänge mich hier mal an.
Meine Ausgangssituation ist nahezu die gleiche, mit dem Unterschied, dass ich den NPS und die CA auf jeweils einem Server 2016 betreibe.
Die Zertifikatsvorlage ist ein Klon der "Computer"-Vorlage, die per Auto-Enrollment GPO dem Client zugewiesen wird.
Um das Verhalten zu testen habe ich nun das Zertifikat an der CA gesperrt und die CRL veröffentlicht. Außerdem habe ich auf allen beteiligten den CRL-Cache gelöscht.
Ich bin schonmal so weit, dass ich per "certutil -verify [cer-file]" auf dem Client sehe, dass das Zertifikat gesperrt wurde.
Ebenfalls habe ich (wie in Colinardos Link beschrieben)auf dem NPS den Registry-Key für die Deaktivierung des TLS-Handle Caches gesetzt:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"ServerCacheTime"=dword:00000000 Alternativ dazu habe ich auch mal 14 Stunden abgewartet. Das Problem war allerdings immer noch: die Authentifizierung per 802.1X des Clients wurde - trotz dem gesperrten Zertifikat - zu keiner Zeit vom NPS abgewiesen. Wenn ich das Computerkonto deaktiviere oder aus der (auf dem NPS berechtigen) Gruppe werfe, weist der NPS die Anfrage erwartungsgemäß ab.
Der Sinn sollte aber doch sein, dass (früher oder später) auch bei einem gesperrten Zertifikat kein Zugriff mehr möglich ist.
Wo könnte hier das Problem liegen?
Gruß, JD
Servus JD,
ja das war schon immer mal ein Problem, nur der obige Key reicht aber definitiv inzwischen nicht mehr aus. Die Anleitungen dazu haben schon einige Zeit auf dem Buckel, und hat mir seinerzeit auch Kopfschmerzen bereitet:
Zumindest der folgende Eintrag muss noch dazu auf 0 gesetzt sein der die maximale Größe des Caches definiert damit der Cache nicht mehr wirksam ist und geleert wird:
Reboot des NPS obligatorisch.
Weitere Einträge siehe:
https://docs.microsoft.com/de-de/windows-server/security/tls/tls-registr ...
Zusätzlich muss natürlich sichergestellt sein das die CRL vom NPS über die im Zertifikat eingetragene CRL-URL abrufbar ist, aber das hast du sicherlich auch schon überprüft denke ich.
Anforderungen an Zertifikate
https://docs.microsoft.com/de-de/windows-server/networking/technologies/ ...
Ich habe aber im laufenden Betrieb auch schon mehrmals feststellen müssen das sich der NPS ab und zu nicht an die Caching-Policy Keys hält, ein Muster konnte ich noch nicht ausmachen. K.A. was die Redmonder da umtreibt so eine Funktionalität nicht bombenfest und Bugfrei zu implementieren, aber der wurde ja schon länger nicht mehr besonders gepflegt. Hier hilft dann so wie du auch schon gelesen und angewendet hast das Deaktivieren oder Entfernen des Users aus der befähigten Gruppe, wie MS ja auch lustigerweise auch selbst schreibt (*Koppschüttel*).
Als Radius kommt mir ein NPS in dem Zusammenhang persönlich jedenfalls nicht mehr in die Tüte.
Grüße Uwe
ja das war schon immer mal ein Problem, nur der obige Key reicht aber definitiv inzwischen nicht mehr aus. Die Anleitungen dazu haben schon einige Zeit auf dem Buckel, und hat mir seinerzeit auch Kopfschmerzen bereitet:
Zumindest der folgende Eintrag muss noch dazu auf 0 gesetzt sein der die maximale Größe des Caches definiert damit der Cache nicht mehr wirksam ist und geleert wird:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\MaximumCacheSizeWeitere Einträge siehe:
https://docs.microsoft.com/de-de/windows-server/security/tls/tls-registr ...
Zusätzlich muss natürlich sichergestellt sein das die CRL vom NPS über die im Zertifikat eingetragene CRL-URL abrufbar ist, aber das hast du sicherlich auch schon überprüft denke ich.
Anforderungen an Zertifikate
https://docs.microsoft.com/de-de/windows-server/networking/technologies/ ...
Ich habe aber im laufenden Betrieb auch schon mehrmals feststellen müssen das sich der NPS ab und zu nicht an die Caching-Policy Keys hält, ein Muster konnte ich noch nicht ausmachen. K.A. was die Redmonder da umtreibt so eine Funktionalität nicht bombenfest und Bugfrei zu implementieren, aber der wurde ja schon länger nicht mehr besonders gepflegt. Hier hilft dann so wie du auch schon gelesen und angewendet hast das Deaktivieren oder Entfernen des Users aus der befähigten Gruppe, wie MS ja auch lustigerweise auch selbst schreibt (*Koppschüttel*).
Als Radius kommt mir ein NPS in dem Zusammenhang persönlich jedenfalls nicht mehr in die Tüte.
Grüße Uwe
1
