Zertifikate sperren

[StefanWe 14]

Hallo,

 

wir nutzen Zertifikate für unsere Computer zur WLAN Authentifizierung. Wollen aber auch User Zertifikate für VPN Tunnel und andere Dinge nutzen. Die Frage ist, bei über 1000 Usern und entsprechenden Zertifikaten, wie sperrt man diese, wenn das Gerät verloren geht, bzw. der Benutzer das Unternehmen verlässt. 

Das Benutzer/Computer Objekt mal eben deaktivieren ist kein Problem. Aber in der MMC für Zertifikate das richtige Zertifikat finden, ist schon schwierig. 

 

Wie wird das gehandhabt in großen Umgebungen ?

[NilsK 2.930]

Moin,

 

das Zertifikat zu sperren, ist nur ein wichtiger Schritt, wesentlicher in solchen Szenarien ist das Sperren des Accounts. Nur dann verliert der User wirklich sofort den Zugriff. Bis das gesperrte Zertifikat in der Sperrliste steht und diese neu auf den Clients bzw. dem VPN-Endpunkt ankommt, kann es durchaus Tage oder Wochen dauern.

 

Das richtige Zertifikat zu finden und zu sperren, kann eine Herausforderung sein. Da hilft es, wenn man den Gesamtprozess im Griff hat und es für jeden User und Zweck nur ein Zertifikat gibt, nicht mehrere parallel, was in vielen Umgebungen Usus ist. "Versehentlich" ausgestellte oder ersetzte Zertifikate sollte man immer sofort sperren. Ebenso sind aussagekräftige Namen bei den Vorlagen hilfreich. Auch hilft es, abgelaufene Zertifikate aus der Datenbank zu entfernen:

https://gallery.technet.microsoft.com/scriptcenter/Script-to-delete-expired-8fcfcf48

 

Neben der MMC könnte man auch per PowerShell arbeiten, was je nach Prozess und Umgebungsstruktur den Vorgang beschleunigen kann. Dazu ist das Modul auf Github nützlich:

https://github.com/Crypt32/PSPKI

 

Gruß, Nils

 

 

 

[StefanWe 14]

Mh. Ich hab’s befürchtet. Hätte gehofft, zum Beispiel durch die Veröffentlichung von Zertifikaten im AD werden diese beim Deaktivieren des Objektes direkt gesperrt. 

 

 

[NorbertFe 2.027]

Das interessiert aber extern niemanden. Und außerdem ist das abrufen der crl afaik Clientangelegenheit.

[NilsK 2.930]

Moin,

 

das Veröffentlichen von Zertifikaten im AD wird weithin missverstanden. Das ist für fast keinen Einsatzzweck interessant; die einzige einigermaßen "übliche" Situation ist interne Mailverschlüsselung: Ein interner User, der einem anderen internen User eine verschlüsselte Mail senden will, kann per AD-Lookup dessen Zertifikat erhalten und muss es nicht erst anfordern (was voraussetzt, dass der Mail-Client das tut). Mehr passiert da nicht, es ist ein reines Datenfeld ohne weitere Logik. Das Zertifikat wird nicht für Logons verwendet, es gibt keine Sperrprozesse, und es wird auch nicht auf den Client übertragen, an dem der User arbeitet. Es gibt auch keine Verbindung von dem AD-Feld zur CA.

 

Die CRL zu verarbeiten ist, wie Norbert schon sagt, Sache des Clients. Die meisten Clients tun das und akzeptieren ein Zertifikat nicht, wenn sie die CRL nicht finden oder diese abgelaufen ist. Das kann eine Stolperstelle in einer PKI sein. Und: Der Client sucht erst dann eine neue CRL, wenn seine lokale Kopie abgelaufen ist - da kommt die CRL-Lifetime ins Spiel, die das Sperren von Zertifikaten für "harte" Sicherheitsanforderungen eigentlich uninteressant macht (weswegen man es aber nicht weglassen darf, es darf nur nicht die einzige Maßnahme sein).

 

Gruß, Nils

 

[NorbertFe 2.027]

Ich glaube Cisco nutzt auch AD veröffentlichte Zertifikate für die Binary Certificate Comparison in der ISE, um mal noch ein anderes Praxisbeispiel zu nennen, welches ich tatsächlich schon live beim Kunden gesehen habe. ;)

https://www.cisco.com/c/en/us/support/docs/lan-switching/8021x/116018-config-8021-00.html

 

Bin da aber nicht tief genug in der Cisco Materie.

 

Bye

Norbert

[StefanWe 14]

Ok. Vielen Dank. Crl und ocsp sind sauber bei uns konfiguriert.