Zertifikat oder 2 Faktor Authentifizierung am Netscaler

Aufgabenbeschreibung

In einem Unternehmen werden mobile Geräte, die mit einem Client-Zertifikat ausgestattet sind, als sicher klassifiziert. Benutzer, die sich mit einem sicher [Authentizität und Integrität] klassifizierten Geräten am Netscaler melden, benötigen nur eine einfache Authentifizierung um auf das Unternehmensnetzwerk zuzugreifen (SSLVPN/ICA PROXY/SSL Offloading). Geräte, die als nicht sicher klassifiziert werden, müssen eine 2 Faktor Authentifizierung durchlaufen. In dieser konkreten Lösung wollen wir sicheren Geräten einen SSL-VPN zur Verfügung stellen, unsicheren Geräten nur Zugriff auf eine Unternehmenswebsite

SSL Vorbereitungen

Der Netscaler hat die Möglichkeit, eine eigene kleine CA zu betreiben. Für unsere Labumgebung ist dieses völlig ausreichend. Die CA hat in unserem Beispiel zwei Aufgaben. Sie zertifiziert den öffentlichen Schlüssel für die Netscaler Zugriff Seite, und stellt ebenfalls Client Zertifikate aus. In größeren Unternehmens Strukturen wird dieses meist nicht von derselben CA realisiert. Das Netscaler Gateway Website Zertifikat sollte von einer öffentlichen, aus dem WAN erreichbaren CA ausgestellt werden. Die Client Zertifikate können von einer Unternehmens CA ausgestellt werden. Diese muss nicht aus dem WAN erreichbar sein, sollte aber für CRL oder OCSP Prüfungen mit dem Netscaler kommunizieren können. Der Netscaler bringt von Haus aus einige sehr bequeme Wizards mit. Auch bei der Erstellung von Zertifikaten können diese recht hilfreich sein. Die SSL Wizard findet man unter dem Menüpunkt Traffic Management->SSL. Wie man eine CA erstellen, öffentliche Schlüssel mit Hilfe der Netscaler CA signiert und anschließend zurückruft beschreibe ich in einem anderen Block Artikel.Wenn der Wizard erfolgreich durchgelaufen ist, findet man das Ergebnis unter Certificate. Im Anschluss sollten das Website Zertifikat noch mit dem Root Zertifikate verlinkt werden, um die vollständige Zertifikatskette bereitzustellen.

NetScaler Gateway anlegen

Create NetScaler Gateway VirtualServerWenn alle Zertifikate erfolgreich erstellt worden sind, kann man unter dem Menüpunkt NetScaler Gateway->Virtual Server eine NetScaler Gateway Site erstellen. In unserer Labumgebung hat die Site die IP 192.168.11.70 und repräsentiert den Zugriff aus dem WAN. Damit der VServer seine Dienste erfüllen kann, benötigt er noch ein SSL Zertifikat. Hierbei sollte beachtet werden, dass der komplette SSL Chain bereitgestellt wird. Deshalb binden wir neben dem Website Zertifikat cag.netscaler.local auch das Root-CA Zertifikat NetScaler-CA als CA an den VServer. Einige Browser warnen nur, wenn der Chain nicht komplett zur Verfügung steht, der Internet Explorer hingegen in seinen default Einstellungen verweigert die Anzeige komplett.

CLI Lösung:

set ssl vserver cag.netscaler.local -tls 11 DISABLED -tls 12 DISABLED
add vpn vserver cag.netscaler.local SSL 192.168.11.70 443 -cginfraHomePageRedirect DISABLED
add ssl certKey NetScaler-Root-CA -cert NetScaler-Root-CA.cer -key NetScaler-Root-CA.key
add ssl certKey CAG.NetScaler.local -cert CAG.NetScaler.local.cer -key CAG.NetScaler.local.key

 Clientzertifikats Authentifizierung

Grundsätzlich könnte unsere CA aus Punkt 1 ebenfalls unsere Client Zertifikate signieren. Wir wollen allerdings versuchen so dicht wie möglich an den Realbedingen zu bleiben und nutzen deshalb eine separate CA und eine Intermediate, die den Client Zertifikat Request signiert hat.  In produktiv Umgebungen hat man meist eigene Windows CA, die für die Ausstellung der Zertifikate zuständig sind. Auch werden intermediate CA genutzt um an SCEP Server zu binden. Diese ermöglichen bei MDM Lösungen Client Zertifikate automatisch zu beantragen und zu verteilen. Das Client Zertifikat, welches aus dem Zertifikat und aus dem Private Key besteht, kann man im Netscaler via pkcs12 exportieren.

 

Create NetScaler Gateway VirtualServer ClientCANun müssen wir den Zertifikats-Chain im VServer hinterlegen, damit der Vserver beim SSL Handshake den Client auffordern kann, die Zertifikate zu senden. Mit der SKIP Checkbox in der GUI können wir CAs, die für den kompletten Chain vorhanden sein müssen, als gültige Client CA ausschliessen. Somit ist sichergestellt, dass nur Client-Zertifikate von der Intermediate angenommen werden. Bitte bedenken Sie auch, das die Root-CA und die Intermediate CA gültig verlinkt werden muss.

Client AuthenticationDamit der Client im SSL Handshake aufgefordert wird sein Zertifikat zu senden, müssen wir noch Zertifikat Authentifizierung  unter SSL-Parameter aktivieren. Wir können zwischen Mandatory und Optional wählen. In unserem Fall ist Optional die korrekte Wahl, da auch Clients ohne Zertifikat eingeschränkten Zugriff haben sollen. RFC5246 Der Browser wählt in der Regel automatisch ein passendes Zertifikat aus und sendet dieses. Wenn allerdings mehrere passende Zertifikate vorhanden sind, wird der Benutzer aufgefordert eines dieser zu wählen. Um die Benutzerfreundlichkeit zu steigern, sollte man also nie mehr als ein gültiges Zertifikat einer CA in ein und der selben Anwendung haben. Der IE und Chrome benutzen den Windows Zertifikatsstore certmgr.msc, Firefox hingegen bringt seinen eigenen Zertifikatsstore mit. Dieser ermöglicht beim SSL Handshake zertifikate zu bestätigen und hilft somit beim Troubleshooting.

CLI Befehle:

set ssl vserver cag.netscaler.local -clientAuth ENABLED -tls11 DISABLED -tls12 DISABLED
bind ssl vserver cag.netscaler.local -certKeyName NetScaler-Root-CA -CA skipCAName -ocspCheck Optional
bind ssl vserver cag.netscaler.local -certKeyName NetScaler-Intermediate-CA -ocspCheck Optional

Vorbereitung LOGIN Seite

Abhängig vom Client Zertifikat muss der Server unterschiedliche LOGIN Seite bereitstellen. In ähnlicher Form wird dieser Vorgehen in einem Citrix Artikel beschrieben. CTX123736 In diesem Artikel wird ein und derselbe Vserver eines Netscaler Gateway durch unterschiedliche URLs aufgerufen. In unserem Beispiel wollen wir den Responder allerdings nicht durch eine URL antriggern, sondern durch ein Client Zertifikat.