WinSrv2012 / Zertifizierungsstelle / Zertifikat blockieren / VPN

[HenryS 0]

Hallo zusammen,

 

seit längerer Zeit beobachte ich ein Problem bei der Sperrung von Zertifikaten. Trotz der Sperrung kann ein Benutzer weiterhin auf zb. auf einen VPN Server mittels seiner SSTP Verbindung verbinden.

 

Mein Aufbau:

 

DC1= Domain Controller (Unternehmensstammzertifizierungsstelle)

VPN= VPN Server (Memberserver, Routing und Ras)

Win7= Clientcomputer (Win7, Mitglied der Domäne)

 

Alle Systeme sind in einer Testumgebung und im gleichen Subnetz. (Auch in einer real nachgestellten Struktur mit getrennten Netzen tritt das Problem auf.)

Der VPN Server hat über den IIS ein Webserverzertifikat erstellt. Der Win7-Client hat ein Benutzerzertifikat über die MMC Konsole vom DC1 angefordert.

 

Die Sperrliste wurde ebenfalls ergänzt und die Überprüfung scheint zu klappen. Kein Fehler:

Fehler „0x80092013“

Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

 

Mein Problem:

Wenn ich das Zertifikat für den Benutzer auf der Zertifizierungsstelle sperre (Zertifikat blockieren)

Dann kann sich der Benutzer trotzdem noch über viele Stunden auf dem VPN Server einloggen.

Unabhängig davon ob ich die Zertifikatssperrlisten erneut ausstelle/aktualisiere.

Das will ich natürlich verhindern und möchte erreichen das der Zugriff SOFORT gesperrt wird.

 

Meine Überlegungen/Fragen dazu:

1. Wenn ich auf dem Zertifikatserver das Zertifikat blockiere, muss doch, unabhängig von der Client Konfiguration (Cache etc.), der Zugriff des Clients bzw. Benutzers unterbunden sein?! Sonst könnte der Client Registry Kniffe oder sonst was anwenden, um sich trotzdem einen Zugang zu verschaffen.

Im Klartext: Am Client kann es nicht liegen bzw. hier muss ich nicht tätig werden.

Das Problem liegt an der Zertifizierungsstelle oder dem VPN Server.

 

2. Unabhängig davon ob ein Client überhaupt die veröffentlichte Sperrliste überprüfen kann oder ob mit dem "NoCertRevocationCheck" Registryeintrag auf dem Client "gearbeitet" wird, darf das keine Auswirkungen auf das Gesperrte Zertifikat haben.

Klartext: Ist das Benutzerzertifikat Serverseitig gesperrt, dann kann der Client machen was er will, er kann keine Verbindung aufbauen, korrekt?!

 

3. Wie erreiche ich eine sofortige Sperrung des Zertifikats so das der Clientbenutzer augenblicklich daran gehindert wird, eine Verbindung zum Server aufzubauen? 

 

 

Vielen Dank

Mfg Henry S.

[NilsK 2.934]

Moin,

 

tjaja, an der Stelle können sich so manche Tücken verbergen, die systemimmanent sind.

 

Zunächst mal gehe ich davon aus, dass wir hier über Clientzertifikate reden, also der Client präsentiert ein Zertifikat, mit dem er sich dem VPN-Gateway gegenüber ausweist. In dem Moment muss nicht der Client auf die Sperrliste zugreifen, sondern das VPN-Gateway. Ist gewährleistet, dass dies funktioniert? Sind die Sperrlisten an allen Downloadpfaden aktuell, die im Zertifikat angeben sind? Üblicherweise muss man die manuell oder über einen separaten Prozess dorthin kopieren, das reine Aktualisieren reicht nicht aus.

 

Dann kann es durchaus sein, dass der Client für die Anmeldung gar nicht das Zertifikat präsentiert, sondern ein separates Cookie (oder was in der Art), um den Prozess zu vereinfachen. Dann hängt es von der Lebensdauer des Cookies ab, wie lange er zugreifen kann. Sowas müsste sich in der Konfig des VPN-Gateways steuern lassen.

 

Das nur als zwei Ansätze, über die ich schon gestolpert bin.

 

Gruß, Nils

[HenryS 0]

Hallo Nils,

 

danke für die Antwort. Es geht tatsächlich um Benutzerzertifikate auf Seite des Clients. zb. für den angemeldeten Benutzer: Benutzer1

(Mit Computerzertifikaten auf Seiten des Clients, komme ich nicht weit.)

Dieser holt sich sein Zertifikat über die Mmc Konsole. Das angeforderte Zertifikat wird auch unter den ausgestellten Zertifikaten mit angezeigt.

Die Zertifikatssperrliste (Zertifizierungsstelle -> Erweiterungen) weist die korrekten Veröffentlichungspunkte aus. Sowohl mit http Pfad als auch mit Dateisystem Pfadangabe. Die Sperrlisten lassen sich auch ohne weitere Probleme dort veröffentlichen. Die normale Sperrliste als auch die Deltasperrliste.

In den ausgestellten Benutzerzertifikaten zb. für Benutzer1, stehen auch die Pfadangaben unter Zertifikatdetails -> Sperrlisten mit drin.

Auch die Sperrlisten selbst enthalten das gesperrte Zertifikat des Benutzers.

Daher, das erneute Ausstellen der Sperrlisten über die Zertifizierungsstelle -> Gesperrte Zertifikate .. funktioniert und überschreibt

im Dateisystem die alten ausgestellten Sperrlisten mit den neuen, welche auch die aktualisierte Werte enthalten.

 

In Puncto Cookies bin ich überfragt, da kommt dann meine Frage ins Spiel.

[zahni 554]

Wenn Du erreichen möchtest, dass ein Client-Cert sofort  gesperrt wird, kommst Du um einen Online-Responder nicht herum. Dateibasierte CRLs werden am Client in der Regel gecacht und können daher veraltet sein.

[NilsK 2.934]

Moin,

 

kann denn das VPN-Gateway auf mindestens einen aktuellen CRL-Pfad zugreifen?

Tut es das auch?

Steht der Pfad, auf den das Gateway zugreifen kann, in der Liste vorne? Da kann es z.B. zu Timeouts kommen.

Kann das Gateway mit Delta-CRLs umgehen?

Sind wirklich alle Speicherorte aktualisiert? Wie gesagt, dort muss man sie manuell oder per Skript hinkopieren, die Aktualisierung selbst betrifft nur die "Hauptkopie", aber nicht die anderen Pfade.

 

Gruß, Nils

[zahni 554]

PS: unter Windows löscht man den CLR-Cache mit

 

certutil -urlcache * delete

[HenryS 0]

Danke für die Antworten,

 

Zu Zahni:

Kann ich den Online Responder nachträglich installieren und mit den bestehenden Zertifikaten verwenden?

Wo installiere ich den Online Responder am besten, auch auf dem VPN Server bzw. dort wo ich die Sperrlisten veröffentlicht habe?

 

Der Befehl: Certutil -urlcache * delete ..

löscht jede Menge auf dem DC1 und Clientcomputer. Hier die Meldung für den Client. Beim DC1 sinds 35. Und beim VPN Server 0 Einträge.

Die CertUtil Meldung ist bei allen gleich.

Allerdings wird das Zertifikat trotzdem nicht gesperrt. bzw. lässt sich immer noch verwenden. Habs nun auch mit dem Webserver Zertifikat probiert, genauso.

 

{

Gelöschte WinINet-Cacheeinträge: 4

 

CertUtil: -URLCache-Befehl ist fehlgeschlagen: 0x80070103 <WIN32/HTTP: 259>

CertUtil: Es sind keine Daten mehr verfügbar.

}

 

Zu Nils:

Wie kann ich das am besten überprüfen mit dem Zugriff?

bearbeitet 28. April 2017 von HenryS

[NilsK 2.934]

Moin,

 

Dir scheint nicht ganz klar zu sein, wer da überhaupt die Zertifikate prüft, oder? Wenn, dann musst du den Cache auf dem Gateway löschen, nicht auf einem Client oder dem DC.

 

Den Online-Responder installiert man auf der CA (in sehr kleinen Umgebungen) oder separat, jedenfalls wird er in die CA eingebunden. Ob dein Gateway damit umgehen kann, ist damit aber noch nicht gesagt.

 

Vielleicht solltest du dich mal an den Hersteller deiner VPN-Lösung wenden, welche auch immer das ist.

 

Gruß, Nils

[HenryS 0]

Hallo,

 

ich realisiere alles über den Windows Server 2012 R2, ich habe keine weitere Hardware/Software Lösung mit drin. Ich möchte einfach einen Win7 Client Computer an den VPN Server anbinden welche sich alle innerhalb einer Domäne befinden.

Der Online Responder selbst sollte doch auch auf einem Webserver liegen um von außen für externe Clients, genauso wie die Sperrlisten, erreichbar sein oder nicht? Bedeutet, ich bräuchte neben dem DC1 der intern steht, auf dem VPN Server, welcher als Edgeserver (2 Netzwerkkarten, eine im internen, eine im externen Netz), eine weitere Zertifizierungsstelle um zumindest den Online Responder dort zu installieren, korrekt?