Der Citrix Netscaler bzw. der Citrix ADC (Application Delivery Controller), wie er nun heißt, bekommt mit der aktuellen Build 12.1 49.23 TLS1.3 Support.
Nachdem die aktuelle Firmware heruntergeladen und auf die beiden ADCs kopiert wurde, fangen wir, wie üblich, mit dem Update des ersten bzw. des Standby Citrix ADC an. Hier vorab noch der offizielle Citrix KB Artikel zum Update: https://support.citrix.com/article/CTX127455
save config
shell
cd /var/nsinstall/build-12.1-49.23_nc_64/
tar -zxvf build-12.1-49.23_nc_64.tgz
#hier wird entpackt
./installns
#hier wird installiert
Reboot NOW? [Y/N] Y
Nach dem Reboot wieder mit der Secondary Citrix ADC Appliance verbinden und überprüfen, ob es tatsächlich die Secondary Appliance ist. 😉 Sofern dies der Fall ist, wird die HA Synchronisation deaktiviert und ein Failover erzwungen.
show ha node
#hier werden die Nodes und der Status angezeigt
set ha node -hasync disabled
force failover
exit
Jetzt geht es mit dem zweiten Citrix Netscaler weiter, der sich nun im Status der Secondary Appliance befindet. Dort wird der obige Vorgang einfach wiederholt.
save config
shell
cd /var/nsinstall/build-12.1-49.23_nc_64/
tar -zxvf build-12.1-49.23_nc_64.tgz
#hier wird entpackt
./installns
#hier wird installiert
Reboot NOW? [Y/N] Y
Direkt nach dem Reboot erneut mit der jetzigen Secondary Citrix ADC Appliance verbinden und mit
show ha node
#hier werden die Nodes und der Status angezeigt
force failover
exit
den HA Status prüfen sowie zurück schwenken, sodass die (alte) Primary Appliance wieder den Status „primary“ hat. Weiter geht es auf die (alte) Secondary Appliance, um dort den HA Sync wieder zu aktivieren.
set ha node -hasync enabled
exit
Nachdem dann jetzt nach dem Update der langweilige „Business as usual“ Teil hinter uns ist, können wir uns dem spannenden und neuen TLS1.3 widmen – Yay! 🙂 Dazu muss im ersten Step die neue SSL Cipher Group „TLSv1.3“ an einen VServer gebunden werden. In meinem Fall nehme ich dazu einmal unseren Unified Gateway Content Switching VServer sowie einen https CS VServer für unsere Exchange Bereitstellung. Zum Abschluss muss dann in den SSL Parametern natürlich noch TLS1.3 aktiviert werden.
bind ssl vserver <Name des Unified Gateway VServers> -cipherName TLSv1.3
bind ssl vserver <Name des Content Switch VServers> -cipherName TLSv1.3
set ssl vserver <Name des Unified Gateway VServers> -ssl3 DISABLED -tls1 DISABLED -tls13 ENABLED
set ssl vserver <Name des Content Switch VServers> -ssl3 DISABLED -tls1 DISABLED -tls13 ENABLED
Notiz am Rande: Um in den Genuss von TLS1.3 am Client zu kommen wird mindestens Google Chrome in Version 65 oder der Mozilla Firefox 61 benötigt.
Und zu guter Letzt die Frage nach dem Warum bzw. welche Vorteile bringt TLS1.3 jetzt?
- TLS1.3 ist dank „Zero Round Trip Time“ schneller im Verbindungsaufbau (TLS1.2: 2 Round Trips; TLS1.3: 1 Round Trip)
- TLS1.3 nutzt per default PFS (Perfect Forward Secrecy)
- TLS1.3 verzichtet auf veraltete und unsichere Ciphers / Hashes
- SHA-1
- RC4
- DES
- 3DES
- AES-CBC
- MD5
- TLS1.3 ist „einfacher“. Dadurch ist es durchaus schwieriger etwas falsch zu konfigurieren. 😉
Jetzt klappts auch wieder mit einem A+ bei SSLLabs.com!
Schreibe einen Kommentar