Jump to content

Smartcardzertifikat sperren?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo und danke für die Aufnahme in eurem Forum,

ich sitze hier seit 2 Tagen vor einem Problem und finde keine passende Lösung, weder per SuFu noch mit Onkel Google.

 

Wir möchten bei uns YubiKeys zur Authentifizierung der User einsetzen. Per PIV und Zertifikatserstellung funktioniert das zertifizieren einwandfrei, ebenso ist die Anmeldung - auch über mehrere RDP-Sessions - ohne Probleme möglich.

Was ist allerdings, wenn ein User mal das Unternehmen verlassen sollte, bzw. jemand seinen Key verliert?

Ich habe hier einen YubiKey mit unserem Testaccount liegen und dieses Zertifikat gesperrt und die Sperrliste veröffentlicht, auch nach mehreren Neustarts kann sich der User ganz normal am System anmelden.

 

Was ich ebenfalls probiert habe:

certutil -urlcache * delete

 

Wenn ich das Zertifikat per certutil verify checke sagt mir auch, dass jenes Zertifikat gesperrt wurde. Über die MMC-Konsole wird es allerdings weiterhin ganz normal als "gültig" deklariert.

 

Kennt jemand die Problematik oder hat evtl. sogar einen Workaround für das schnelle sperren von Zertifikaten bzw. SmartCards?

 

Liebe Grüße aus dem Rhein-Main Gebiet!:hallo:

Link zu diesem Kommentar

Um ein Zertifikat zurückziehen zu können, muss der Server prüfen können, ob ein Zertifikat zurückgezogen wurde. Dazu eine per HTTP muss vom Server und Client erreichbare CRL existieren und in den Zertifikaten konfiguriert sein.

Noch effizienter und sicherer ist die Nutzung eines Online Responders, der auch von beiden Systemen erreichbar sein muss und die Lösung muss damit umgehen können. Sprich: Den Revocation-Check muss der RDP-Server machen.

 

 

 

 

Link zu diesem Kommentar
vor 1 Minute schrieb zahni:

Um ein Zertifikat zurückziehen zu können, muss der Server prüfen können, ob ein Zertifikat zurückgezogen wurde. Dazu eine per HTTP muss vom Server und Client erreichbare CRL existieren und in den Zertifikaten konfiguriert sein.

Noch effizienter und sicherer ist die Nutzung eines Online Responders, der auch von beiden Systemen erreichbar sein muss und die Lösung muss damit umgehen können. Sprich: Den Revocation-Check muss der RDP-Server machen.

 

 

 

 

Danke für die schnelle Antwort. Muss das ganze zwingend per HTTP passieren oder geht das auch über ein SMB-Freigabe im Netzwerk?

Link zu diesem Kommentar

Moin,

das sind *zwei* Anwendungsfälle:

  1. wenn der User das Unternehmen verlässt, sperre sein Account im AD. Das wirkt sich auch auf die Smartcard-Authentifizierung aus.
  2. wenn er seinen Key verliert und Du wirklich nur das Zertifikat zurückziehen möchtest, muss der Domain Controller davon erfahren. Es geht also nicht um den CRL Cache auf den Clients, sondern auf den Domain Controllern.
  • Like 1
  • Danke 1
Link zu diesem Kommentar

Moin,

 

Das Sperren eines Zertifikats ist keine sofort wirksame Sache. Der Client wird erst dann eine neue CRL anfordern, wenn die alte abgelaufen ist. Solange nutzt er die letzte, die er im Cache hat, sie ist ja noch gültig.

 

Daran ändert auch ein Online Responder nichts, weil auch der nur die CRL nutzt. Für zeitkritische Fälle braucht man also immer noch zusätzliche Mechanismen, muss also etwa den User sperren.

 

Gruß, Nils

Link zu diesem Kommentar

Servus und danke für eure Antworten.

 

Die Kontosperrung ist natürlich selbstverständlich, sobald ein User das Unternehmen verlässt. 

Im Falle eines Verlustes der SmartCard möchte der Benutzer natürlich trotzdem weiterarbeiten, deswegen ist eine Kontosperrung - aufgrund einer verlorenen Smartcard - für uns aktuell keine Option.

 

Ich habe über den Befehl:

certutil -verify -urlfetch "..."

jeweils eine Prüfung auf dem Client und allen DC's durchgeführt. Trotzdessen, dass mir angezeigt wird, das Zertifikat wäre gesperrt ist eine Anmeldung jederzeit möglich. 

 

Für den Test habe ich folgendes durchgeführt:

1. Zertifikat erstellt und auf Yubikey gespeichert 

2. Testanmeldung durchgeführt (hat einwandfrei funktioniert)

3. Zertifikat gesperrt und Sperrliste veröffentlicht

4. Zertifikat gecheckt - Zertifikat war noch gültig (wie erwartet)

5. Cache gelöscht 

6. Zertifikat gecheckt - war nun gesperrt (wie erwartet)

 

Nichtsdestotrotz ist die Anmeldung ohne Probleme möglich. In unserer Testumgebung (deutlich kleineres Netzwerk) hat die Sperrung auch ohne Cache-Löschen keine 5 Minuten gedauert und die Anmeldung war nicht mehr möglich. 

 

Link zu diesem Kommentar

Moin,

 

ja, so eine Problemlage tritt immer wieder auf. Man wird sich in solchen Fällen dann auch ansehen müssen, was denn wirklich passiert. Oft stellt man dabei fest, dass man sich in falscher Sicherheit wiegt, nur weil Zertifikate im Spiel sind.

 

So ist es bei vielen Anwendungen so, dass zwar die "Erstanmeldung" ein Client-Zertifikat erfordert, der eigentliche Zugriff aber auf Basis eines Tokens geschieht, dass nach der Anmeldung ausgestellt wird. Solange dieses Token gültig ist, prüft niemand mehr das Zertifikat. Da kann man es dann sperren, so viel man will. So ist das z.B. bei den allermeisten Cloud-Services, die eine Zertifikatsanmeldung erlauben. Die Anbieter (z.B. Microsoft) dokumentieren das auch, man muss aber danach suchen.

 

Auch die Möglichkeit, mit OCSP schneller auf Sperrungen zu reagieren (danke @cj_berlin für die Ergänzung), ändert daran nichts. Zudem ist bei OCSP immer zu berücksichtigen, dass der Client auf die Idee kommen muss, überhaupt nachzufragen, was dann in seinem Ermessen liegt. Und noch dazu wird für OCSP oft eine herkömmliche CRL als Fallback angeboten - ist OCSP also nicht erreichbar, nützt dessen Geschwindigkeitsvorteil auch wieder nix.

 

Es bleibt also dabei: Wenn ein Zugriff schnell entzogen werden muss, muss man eine zertifikatsbasierte Zugriffssteuerung auf jeden Fall durch weitere Mechanismen ergänzen.

 

Edit: Da in deinem Anwendungsfall auch noch eine andere Ebene durchscheint, auch dazu noch eine Anmerkung. Du sagst, dass ihr reagieren wollt, wenn jemand seine Smartcard verliert, aber nicht das Unternehmen verlässt. Hier wollt ihr euch absichern, dass nicht jemand anderes mit der gefundenen/gestohlenen Smartcard sich anmeldet. Hier wäre der korrekte Weg (neben dem Erfordernis, dass zu einer Smartcard auch ein zweiter Faktor wie eine PIN gehören sollte), das vorhandene, ggf. gesperrte Zertifikat von dem Useraccount zu trennen. Der legitime Benutzer braucht dann ja ohnehin eine neue Smartcard, also ein neues Zertifikat mit neuem Private Key. Auch hier würde dir eine schnellere Durchsetzung der Zertifikatssperrung nichts nutzen - diese kann ja erst erfolgen, wenn der Verlust bekannt ist, und sie muss manuell erfolgen. Da gehört es dann zum Prozess, das nicht mehr vertrauenswürdige Zertifikat vom Useraccount zu trennen.

 

Auch dies hilft allerdings nur für Neuanmeldungen, nicht für bestehende Sitzungen. Letztere allerdings gehören auch nicht zu dem Szenario "Smartcard verloren". Wie sich hieraus ergibt, können Smartcards immer nur ein Baustein sein, aber keine ausreichende Lösung für ... irgendwas.

 

Gruß, Nils

PS: dies sind Details, die mich dazu bringen, PKI insgesamt als "krank" zu betrachten.

bearbeitet von NilsK
Link zu diesem Kommentar

Hallo Leute,

 

danke erstmal für eure Hilfe. Kleines Feedback meinerseits: Der entscheidende Tipp kam von @cj_berlin, danke schonmal hierfür!

 

Tatsächlich waren die Zertifikatsvorlagen jeweils in Produktiv- und Testumgebung gleich. Der Unterschied war nur, dass die Zertifizierungsstelle in der Produktivumgebung nicht auf dem DC eingerichtet war.

 

Nachdem das Zertifikat gesperrt wird muss auf dem DC der Befehl 

certutil -setreg chain\ChainCacheResyncFiletime @now

ausgeführt werden. Mit diesem Befehl wird eine Neusynchronisation und Überprüfung der Zertifikate und deren Eigenschaften neu angestoßen.

Im Anschluss daran habe ich ein kleines Script für den Server - welcher die Zertifikate verwaltet - gebaut.

certutil -setreg chain\ChainCacheResyncFiletime @now
net stop CertSvc
timeout 3
net start CertSvc
@Echo Skript beendet
pause

Dasselbe wird dann nochmal auf dem Server der Zertifikatverwaltung ausgeführt und der Dienst "CertSvc" neu gestartet. So konnte ich die Zertifikate binnen 1 Minute sperren.

 

Das ganze war bei einem Test 5x hintereinander zuverlässig.

 

Danke für eure Hilfe!

 

LG Marco

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...