Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
SSL-Offload-Konfiguration
Um das SSL-Offloading zu konfigurieren, müssen Sie die SSL-Verarbeitung auf der NetScaler-Appliance aktivieren und einen SSL-basierten virtuellen Server konfigurieren. Der virtuelle Server fängt SSL-Verkehr ab, entschlüsselt den Datenverkehr und leitet ihn an einen Dienst weiter, der an den virtuellen Server gebunden ist. Um zeitkritischen Datenverkehr wie Medienstreaming zu sichern, können Sie einen virtuellen DTLS-Server konfigurieren. Um das SSL-Offloading zu aktivieren, müssen Sie ein gültiges Zertifikat und einen gültigen Schlüssel importieren und das Paar an den virtuellen Server binden.
Hinweis
Ab Version 13.1 Build 17.x sind Protokolle niedriger als TLSv1.2 in den internen SSL-Diensten deaktiviert. Wenn das (erweiterte) Standardprofil aktiviert ist, ist das Profil
ns_default_ssl_profile_internal_frontend_servicean die internen SSL-Dienste gebunden und die Protokolle SSLv3, TLSv1.0 und TLSv1.1 sind im Profil deaktiviert.
SSL aktivieren
Um SSL-Verkehr zu verarbeiten, müssen Sie die SSL-Verarbeitung aktivieren. Sie können SSL-basierte Entitäten wie virtuelle Server und Dienste konfigurieren, ohne die SSL-Verarbeitung zu aktivieren. Sie funktionieren jedoch erst, wenn die SSL-Verarbeitung aktiviert ist.
SSL-Verarbeitung über die CLI aktivieren
Geben Sie in der Befehlszeile Folgendes ein:
enable ns feature ssl
show ns feature
Beispiel:
enable ns feature SSL
Done
show ns feature
Feature Acronym Status
------- ------- ------
1) Web Logging WL OFF
2) Surge Protection SP ON
3) Load Balancing LB ON
.
.
.
9) SSL Offloading SSL ON
.
.
.
24) NetScaler Push push OFF
Done
SSL-Verarbeitung über die GUI aktivieren
Navigieren Sie zu System > Einstellungen, und klicken Sie in der Gruppe Modi und Funktionen auf Grundfunktionen konfigurieren, und klicken Sie auf SSL-Offloading.
Konfigurieren von Diensten
Auf der NetScaler-Appliance stellt ein Dienst einen physischen Server oder eine Anwendung auf einem physischen Server dar. Nach der Konfiguration befinden sich Dienste im deaktivierten Zustand, bis die Appliance den physischen Server im Netzwerk erreichen und seinen Status überwachen kann.
Hinzufügen eines Dienstes über die CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um einen Dienst hinzuzufügen und die Konfiguration zu überprüfen:
add service <name> (<IP> | <serverName>) <serviceType> <port>
show service <serviceName>
Beispiel:
add service sslsvc 198.51.100.225 SSL 443
Done
sh ssl service sslsvc
Advanced SSL configuration for Back-end SSL Service sslsvc:
DH: DISABLED
DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: DISABLED
Session Reuse: ENABLED Timeout: 300 seconds
Cipher Redirect: DISABLED
SSLv2 Redirect: DISABLED
ClearText Port: 0
Server Auth: DISABLED
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: DISABLED
OCSP Stapling: DISABLED
SSLv2: DISABLED SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.1: ENABLED TLSv1.2: ENABLED TLSv1.3: DISABLED
Send Close-Notify: YES
Strict Sig-Digest Check: DISABLED
Zero RTT Early Data: ???
DHE Key Exchange With PSK: ???
Tickets Per Authentication Context: ???
ECC Curve: P_256, P_384, P_224, P_521
1) Cipher Name: DEFAULT_BACKEND
Description: Default cipher list for Backend SSL session
Done
Ändern oder entfernen Sie einen Dienst über die CLI
Um einen Dienst zu ändern, verwenden Sie den Befehl set service. Dies entspricht genau dem Befehl add service, außer dass Sie den Namen eines vorhandenen Dienstes eingeben.
Um einen Dienst zu entfernen, verwenden Sie den Befehl rm service, der nur das <name> -Argument akzeptiert.
rm service <servicename>
Beispiel:
rm service sslsvc
Um einen Dienst zu ändern, verwenden Sie den Befehl set service, wählen Sie einen beliebigen Parameter aus und ändern Sie seine Einstellung.
set service <name> (<IP> | <serverName>) <serviceType> <port>
Beispiel:
set service sslsvc 198.51.100.225 SSL 443
Konfigurieren Sie einen Dienst über die GUI
Navigieren Sie zu Traffic Management > Load Balancing > Services , erstellen Sie einen Dienst und geben Sie das Protokoll als SSL an.
Virtuelle SSL-Serverkonfiguration
Für sichere Sitzungen muss eine Verbindung zwischen dem Client und einem SSL-basierten virtuellen Server auf der NetScaler-Appliance hergestellt werden. Der virtuelle SSL-Server fängt den SSL-Verkehr ab, entschlüsselt ihn und verarbeitet ihn, bevor er an Dienste gesendet wird, die an den virtuellen Server gebunden sind.
Hinweis: Der virtuelle SSL-Server wird auf der NetScaler-Appliance als heruntergefahren markiert, bis ein gültiges Zertifikat-/Schlüsselpaar und mindestens ein Dienst daran gebunden sind. Ein SSL-basierter virtueller Server ist ein virtueller Lastausgleichsserver vom Protokolltyp SSL oder SSL_TCP. Die Lastausgleichsfunktion muss auf der NetScaler-Appliance aktiviert sein.
Fügen Sie über die CLI einen SSL-basierten virtuellen Server hinzu
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um einen SSL-basierten virtuellen Server zu erstellen und die Konfiguration zu überprüfen:
add lb vserver <name> (serviceType) <IPAddress> <port>
show ssl vserver <name>
Beispiel:
add lb vserver sslvs SSL 192.0.2.240 443
Done
sh ssl vserver sslvs
Advanced SSL configuration for VServer sslvs:
DH: DISABLED
DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: ENABLED Refresh Count: 0
Session Reuse: ENABLED Timeout: 120 seconds
Cipher Redirect: DISABLED
SSLv2 Redirect: DISABLED
ClearText Port: 0
Client Auth: DISABLED
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: DISABLED
OCSP Stapling: DISABLED
HSTS: DISABLED
HSTS IncludeSubDomains: NO
HSTS Max-Age: 0
SSLv2: DISABLED SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.1: ENABLED TLSv1.2: ENABLED TLSv1.3: DISABLED
Push Encryption Trigger: Always
Send Close-Notify: YES
Strict Sig-Digest Check: DISABLED
Zero RTT Early Data: DISABLED
DHE Key Exchange With PSK: NO
Tickets Per Authentication Context: 1
ECC Curve: P_256, P_384, P_224, P_521
1) Cipher Name: DEFAULT
Description: Default cipher list with encryption strength >= 128bit
Done
Ändern oder entfernen Sie einen SSL-basierten virtuellen Server über die CLI
Verwenden Sie den Befehl set lb vserver um die Lastausgleichseigenschaften eines virtuellen SSL-Servers zu ändern. Der Befehl set ähnelt dem Befehl add lb vserver, außer dass Sie den Namen eines vorhandenen virtuellen Servers eingeben. Um die SSL-Eigenschaften eines SSL-basierten virtuellen Servers zu ändern, verwenden Sie den Befehl set ssl vserver. Weitere Informationen finden Sie im Abschnitt “Virtuelle SSL-Server-Parameter” weiter unten auf dieser Seite.
Um einen virtuellen SSL-Server zu entfernen, verwenden Sie den Befehl rm lb vserver, der nur das Argument <name> akzeptiert.
Konfigurieren eines SSL-basierten virtuellen Servers über die GUI
Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Server, erstellen Sie einen virtuellen Server und geben Sie das Protokoll als SSL an.
Binden Sie Dienste an den virtuellen SSL-Server
Die ADC-Appliance leitet entschlüsselte SSL-Daten an Server im Netzwerk weiter. Um Daten weiterzuleiten, müssen Dienste, die diese physischen Server darstellen, an den virtuellen Server gebunden sein, der die SSL-Daten empfängt.
In der Regel ist die Verbindung zwischen der ADC-Appliance und dem physischen Server sicher. Daher muss die Datenübertragung zwischen der Appliance und dem physischen Server nicht verschlüsselt werden. Sie können jedoch End-to-Ende-Verschlüsselung bereitstellen, indem Sie die Datenübertragung zwischen der Appliance und dem Server verschlüsseln. Einzelheiten finden Sie unter Konfigurieren von SSL-Offloading mit Ende-zu-Ende-Verschlüsselung.
Hinweis: Aktivieren Sie die Lastenausgleichsfunktion auf der ADC-Appliance, bevor Sie Dienste an den SSL-basierten virtuellen Server binden.
Binden eines Dienstes an einen virtuellen Server mit der CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um den Dienst an den virtuellen Server zu binden und die Konfiguration zu überprüfen:
bind lb vserver <name> <serviceName>
show lb vserver <name>
Beispiel:
bind lb vserver sslvs sslsvc
Done
sh lb vserver sslvs
sslvs (192.0.2.240:443) - SSL Type: ADDRESS
State: DOWN[Certkey not bound]
Last state change was at Wed May 2 11:43:04 2018
Time since last state change: 0 days, 00:13:21.150
Effective State: DOWN
Client Idle Timeout: 180 sec
Down state flush: ENABLED
Disable Primary Vserver On Down : DISABLED
Appflow logging: ENABLED
No. of Bound Services : 1 (Total) 0 (Active)
Configured Method: LEASTCONNECTION BackupMethod: ROUNDROBIN
Mode: IP
Persistence: NONE
Vserver IP and Port insertion: OFF
Push: DISABLED Push VServer:
Push Multi Clients: NO
Push Label Rule: none
L2Conn: OFF
Skip Persistency: None
Listen Policy: NONE
IcmpResponse: PASSIVE
RHIstate: PASSIVE
New Service Startup Request Rate: 0 PER_SECOND, Increment Interval: 0
Mac mode Retain Vlan: DISABLED
DBS_LB: DISABLED
Process Local: DISABLE
Traffic Domain: 0
TROFS Persistence honored: ENABLED
Retain Connections on Cluster: NO
1) sslsvc (198.51.100.225: 443) - SSL State: DOWN Weight: 1
Done
Trennen Sie einen Dienst über die CLI von einem virtuellen Server
Geben Sie an der Eingabeaufforderung den folgenden Befehl ein:
unbind lb vserver <name> <serviceName>
Beispiel:
unbind lb vserver sslvs sslsvc
Done
Binden Sie einen Dienst über die GUI an einen virtuellen Server
- Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Server.
- Öffnen Sie einen virtuellen Server und klicken Sie im Abschnitt Dienste und Dienstgruppen auf die Kachel Load Balancing Virtual Server ServiceBindings .
- Klicken Sie auf der Seite Load Balancing Virtual Server Service Binding auf die Registerkarte Bindungen hinzufügen, klicken Sie unter Service auswählen auf Klicken, umauszuwählen, und aktivieren Sie das Kontrollkästchen neben dem Dienst, der gebunden werden soll.
- Klicken Sie auf Auswählen und dann auf Binden
Konfigurieren eines virtuellen Servers mit Servernamenangabe (SNI) für das sichere Hosting mehrerer Sites
Virtuelles Hosting wird von Webservern verwendet, um mehr als einen Domainnamen mit derselben IP-Adresse zu hosten. Die Appliance unterstützt das Hosting mehrerer sicherer Domänen, indem sie die SSL-Verarbeitung mithilfe transparenter SSL-Dienste oder virtueller serverbasierter SSL-Offloading von den Webservern auslagert. Wenn jedoch mehrere Sites auf demselben virtuellen Server gehostet werden, ist der SSL-Handshake abgeschlossen, bevor der erwartete Hostname an den virtuellen Server gesendet wird. Daher kann die Appliance nicht ermitteln, welches Zertifikat dem Client nach dem Herstellen einer Verbindung vorgelegt werden soll. Dieses Problem wird gelöst, indem SNI auf dem virtuellen Server aktiviert wird. SNI ist eine Transport Layer Security (TLS) -Erweiterung, die vom Client verwendet wird, um den Hostnamen während der Handshake-Initiierung anzugeben. Die ADC-Appliance vergleicht diesen Hostnamen mit dem allgemeinen Namen und vergleicht ihn, falls er nicht übereinstimmt, mit dem alternativen Antragstellernamen (SAN). Wenn der Name übereinstimmt, legt die Appliance dem Client das entsprechende Zertifikat vor.
Ein Wildcard-SSL-Zertifikat ermöglicht die SSL-Verschlüsselung für mehrere Subdomänen, wenn dieselbe Organisation diese Domänen kontrolliert und der Domainname der zweiten Ebene derselbe ist. Beispielsweise kann ein Wildcard-Zertifikat, das an ein Sportnetzwerk mit dem allgemeinen Namen “*.sports.net” ausgestellt wurde, verwendet werden, um Domänen wie “login.sports.net” und “help.sports.net” zu sichern. Die Domäne “login.ftp.sports.net” kann nicht gesichert werden.
Hinweis: Auf einer ADC-Appliance werden nur die DNS-Einträge für Domainname, URL und E-Mail-ID im SAN-Feld verglichen.
Mit der Option -SNICert können Sie mehrere Serverzertifikate an einen einzelnen virtuellen SSL-Server oder transparenten Dienst binden. Der virtuelle Server oder Dienst stellt diese Zertifikate aus, wenn SNI auf dem virtuellen Server oder Dienst aktiviert ist. Sie können SNI jederzeit aktivieren.
Binden Sie mehrere Serverzertifikate über die CLI an einen einzelnen virtuellen SSL-Server
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um SNI zu konfigurieren und die Konfiguration zu überprüfen:
set ssl vserver <vServerName>@ [-SNIEnable ( ENABLED | DISABLED )]
bind ssl vserver <vServerName>@ -certkeyName <string> -SNICert
show ssl vserver <vServerName>
Um mehrere Serverzertifikate über die CLI an einen transparenten Dienst zu binden, ersetzen Sie vserver in den vorhergehenden Befehlen durch den Dienst und vservername durch den Dienstnamen.
Hinweis: Erstellen Sie den SSL-Dienst mit der Option -clearTextPort 80.
Binden Sie mehrere Serverzertifikate über die GUI an einen einzelnen virtuellen SSL-Server
- Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Server.
- Öffnen Sie einen virtuellen SSL-Server und wählen Sie unter CertificatesServerzertifikataus.
- Fügen Sie ein Zertifikat hinzu oder wählen Sie ein Zertifikat aus der Liste aus, und klicken Sie auf Serverzertifikat für SNI.
- Wählen Sie in den erweiterten EinstellungenSSL-Parameteraus.
- Klicken Sie auf SNI Enable.
Unterstützung für SNI im Back-End-Dienst
Hinweis: SNI wird in einem DTLS-Back-End-Dienst nicht unterstützt.
Die NetScaler-Appliance unterstützt Server Name Indication (SNI) im Backend. Das heißt, der allgemeine Name wird als Servername im Client-Hallo an den Back-End-Server gesendet, damit der Handshake erfolgreich abgeschlossen werden kann. Diese Unterstützung trägt dazu bei, die Sicherheitsanforderungen von Systemintegratoren des Bundes zu SNI bietet außerdem den Vorteil, dass nur ein Port verwendet wird, anstatt Hunderte verschiedener IP-Adressen und Ports in einer Firewall zu öffnen.
Zu den Sicherheitsanforderungen des föderalen Systemintegrators gehört die Unterstützung von Active Directory Federation Services (ADFS) 3.0 in 2012 R2 und WAP-Servern. Um diese Anforderung zu erfüllen, ist die Unterstützung für SNI im Backend einer NetScaler-Appliance erforderlich.
Hinweis:
Damit SNI funktioniert, muss der Servername im Client-Hello mit dem Hostnamen übereinstimmen, der im Back-End-Dienst konfiguriert ist, der an einen virtuellen SSL-Server gebunden ist. Wenn der Hostname des Backend-Servers beispielsweise www.mail.example.com lautet, muss der SNI-fähige Back-End-Dienst mit dem Servernamen als konfiguriert werden https://www.mail.example.com. Und dieser Hostname muss mit dem Servernamen im Client Hello übereinstimmen.
Unterstützung für dynamisches SNI im Back-End-Dienst
Die NetScaler-Appliance unterstützt dynamisches SNI auf den Back-End-TLS-Verbindungen. Das heißt, die Appliance lernt den SNI in der Clientverbindung und verwendet ihn in der serverseitigen Verbindung. Sie müssen keinen allgemeinen Namen mehr im SSL-Dienst, in der Dienstgruppe oder im Profil angeben. Der in der SNI-Erweiterung der Client-Hello-Nachricht empfangene allgemeine Name wird an die Back-End-SSL-Verbindung weitergeleitet.
Zuvor mussten Sie statisches SNI für SSL-Dienste, Dienstgruppen und SSL-Profile konfigurieren. Daher wurde nur die konfigurierte statische SNI-Erweiterung an den Server gesendet. Wenn ein Client gleichzeitig auf mehrere Domänen zugreifen musste, konnte die ADC-Appliance das vom Client empfangene SNI nicht an den Back-End-Dienst senden. Stattdessen wurde der statische allgemeine Name gesendet, der konfiguriert wurde. Wenn der Back-End-Server jetzt für mehrere Domänen konfiguriert ist, kann der Server mit dem richtigen Zertifikat antworten, das auf dem SNI basiert, das in der Client-Hello-Nachricht von der Appliance empfangen wurde.
Zeigen Sie auf Hinweis:
-
SNI muss auf dem Front-End aktiviert sein und das richtige SNI-Zertifikat muss an den virtuellen SSL-Server gebunden sein. Wenn Sie SNI im Front-End nicht aktivieren, werden die SNI-Informationen nicht an das Back-End weitergegeben.
-
Wenn die Serverauthentifizierung aktiviert ist, wird das Serverzertifikat durch das CA-Zertifikat überprüft, und die allgemeinen Name/SAN-Einträge im Serverzertifikat werden mit dem SNI abgeglichen. Daher muss das CA-Zertifikat an den Dienst gebunden sein.
-
Die Wiederverwendung der Back-End-Verbindung und der SSL-Sitzung basiert auf SNI, wenn dynamisches SNI aktiviert ist.
SSL-Monitore senden kein SNI, wenn dynamisches SNI aktiviert ist. Für SNI-basierte Sondierungen fügen Sie den SSL-Monitoren ein Back-End-Profil hinzu, auf dem statisches SNI konfiguriert ist. Der Monitor muss mit demselben benutzerdefinierten Header wie SNI konfiguriert werden.
Konfigurieren von SNI im Back-End-Dienst über die CLI
Geben Sie in der Befehlszeile Folgendes ein:
add service <name> <IP> <serviceType> <port>
add lb vserver <name> <IPAddress> <serviceType> <port>
bind lb vserver <name> <serviceName>
set ssl service <serviceName> -SNIEnable ENABLED -commonName <string>
set ssl profile <name> -SNIEnable ENABLED
Beispiel:
add service service_ssl 198.51.100.100 SSL 443
add lb vserver ssl-vs 203.0.113.200 SSL 443
bind lb vserver ssl-vs service_ssl
set ssl service service_ssl -SNIEnable ENABLED –commonName www.example.com
set ssl profile sslprof -SNIEnable ENABLED
Konfigurieren Sie SNI im Back-End-Dienst über die GUI
- Navigieren Sie zu Traffic Management > Load Balancing > Services.
- Wählen Sie einen SSL-Dienst aus und klicken Sie in Erweiterte Einstellungenauf SSL-Parameter.
-
Klicken Sie auf SNI Enable.
Konfigurieren Sie SNI im SSL-Profil über die GUI
- Navigieren Sie zu System > Profile > SSL-Profil.
- Klicken Sie auf Hinzufügen .
-
Wählen Sie in den GrundeinstellungenSNI-Aktivierungaus.
- Klicken Sie auf OK.
Binden Sie einen sicheren Monitor an einen SNI-fähigen Back-End-Dienst
Sie können sichere Monitore vom Typ HTTP, HTTP-ECV, TCP oder TCP-ECV an die Back-End-Dienste und Dienstgruppen binden, die SNI unterstützen. Die Monitor-Prüfpunkte senden jedoch nicht die SNI-Erweiterung, wenn dynamisches SNI aktiviert ist. Um SNI-Prüfungen zu senden, aktivieren Sie statisches SNI im Back-End-SSL-Profil und binden Sie das Profil an den Monitor. Stellen Sie den benutzerdefinierten Header im Monitor auf den Servernamen ein, der als SNI-Erweiterung im Client-Hello der Monitorprobe gesendet wird.
Konfigurieren und binden Sie einen sicheren Monitor über die CLI an einen SNI-fähigen Back-End-Dienst
Geben Sie in der Befehlszeile Folgendes ein:
add lb monitor <monitorName> <type> -secure YES
add ssl profile <name> -sslProfileType BackEnd
set lb monitor <monitorName> <type> -customHeaders <string> -sslprofile <backend ssl profile>
set ssl profile <name> -sniEnable ENABLED -commonName <string>
bind service <name> -monitorName <string>
Beispiel:
add ssl profile sni_backend_profile -sslProfileType BackEnd
set ssl profile sni_backend_profile -sniEnable ENABLED -commonName example.com
add lb monitor http-ecv-mon HTTP-ECV -secure YES
set monitor http-ecv-mon HTTP-ECV -customHeaders "Host: example.com\r\n" -sslprofile sni_backend_profile
bind service ssl_service –monitorName http-ecv-mon
Konfigurieren und binden Sie einen sicheren Monitor über die GUI an einen SNI-fähigen Back-End-Dienst
- Navigieren Sie zu System > Profile > SSL-Profile.
- Klicken Sie auf Hinzufügen .
-
Geben Sie einen Namen für das Profil an und wählen Sie unter SSL-ProfiltypBackendaus.
-
Geben Sie den allgemeinen Namen an (entspricht dem Host-Header) und wählen Sie SNI Enable.
- Klicken Sie auf OK.
- Navigieren Sie zu Traffic Management > Load Balancing > Monitor .
- Klicken Sie auf Hinzufügen .
- Geben Sie einen Namen für den Monitor an. Wählen Sie unter Typdie Option HTTP, HTTP-ECV, TCP oder TCP-ECV aus.
-
Geben Sie einen benutzerdefinierten Headeran.
- Wählen Sie Sicheraus.
- Wählen Sie im SSL-Profildas Back-End-SSL-Profil aus, das in den vorherigen Schritten erstellt wurde.
-
Klicken Sie auf Erstellen.
- Navigieren Sie zu Traffic Management > Load Balancing > Services.
- Wählen Sie einen SSL-Dienst und klicken Sie auf Bearbeiten.
- Klicken Sie unter Monitoreauf Bindung hinzufügen, wählen Sie den in den vorherigen Schritten erstellten Monitor aus und klicken Sie auf Binden.
Konfigurieren und binden Sie einen sicheren Monitor über die GUI an einen SNI-fähigen Back-End-Dienst
- Navigieren Sie zu Traffic Management > Load Balancing > Monitor.
- Fügen Sie einen Monitor vom Typ HTTP-ECV oder TCP-ECVhinzu und geben Sie einen benutzerdefinierten Headeran.
- Wählen Sie Create.
- Navigieren Sie zu Traffic Management > Load Balancing > Services .
- Wählen Sie einen SSL-Dienst und klicken Sie auf Bearbeiten.
- Klicken Sie unter Monitoreauf Bindung hinzufügen, wählen Sie den in Schritt 3 erstellten Monitor aus und klicken Sie auf Binden.
Lassen Sie den Handshake für einen unbekannten Servernamen weiterlaufen
Hinweis
Diese Funktion ist in Version 13.1 Build 45.x und höher verfügbar.
Wenn SNI aktiviert ist und die NetScaler-Appliance ein Client-Hello mit einem unbekannten Servernamen empfängt, beendet sie den SSL-Handshake. Ab Version 13.1 Build 45.x ermöglicht die Appliance, dass der SSL-Handshake auch für einen unbekannten Servernamen fortgesetzt wird, und überlässt dem Client die Entscheidung, den Handshake zu beenden oder abzuschließen. Sie können diese Einstellung in einem Front-End-SSL-Profil konfigurieren, wenn SNI mithilfe des allowUnknownSNI Parameters AKTIVIERT ist.
Lassen Sie diesen Parameter deaktiviert, wenn Sie eine Weiterleitungsaktion für eine SNI-basierte Regel verwenden müssen. Sie haben beispielsweise SNI auf dem virtuellen Server v1 aktiviert und eine Richtlinie konfiguriert, um alle Anfragen für eine bestimmte Domain (www.example.com) an den virtuellen Server v2 weiterzuleiten. Bisher wurden alle Anfragen, die auf Version 1 für diese Domain eingehen, automatisch an Version 2 weitergeleitet. Wenn der allowunknownSNI Parameter jedoch aktiviert ist, wird die Anfrage auf v1 verarbeitet. Der Parameter muss deaktiviert sein, damit die Appliance die Anfrage auf v1 verarbeiten kann.
Konfigurieren Sie „Unbekanntes SNI zulassen“ mithilfe der CLI
Geben Sie in der Befehlszeile Folgendes ein:
set ssl profile default_profile -SNIEnable Enabled -allowUnknownSNI <DISABLED/ENABLED>
Der Parameter `allowUnknownsNI ist standardmäßig deaktiviert. Infolgedessen bricht die Appliance den Handshake für einen unbekannten Servernamen ab. Um diese Einstellung zu aktivieren, geben Sie Folgendes ein:
set ssl profile default_profile -SNIEnable Enabled -allowUnknownSNI ENABLED
Konfigurieren Sie „Unbekanntes SNI zulassen“ mithilfe der GUI
- Navigieren Sie zu System > Profile > SSL-Profil.
- Wenn Sie ein Profil hinzufügen, wählen Sie in der Liste SSL-Profiltyp die Option FrontEnd aus. Andernfalls können Sie ein vorhandenes Frontend-Profil bearbeiten.
-
Wählen Sie Unbekanntes SNI zulassenaus.
- Klicken Sie auf OK und dann auf Fertig.
Hinzufügen oder Aktualisieren eines Zertifikatsschlüsselpaars
Hinweise:
Wenn Sie kein vorhandenes Zertifikat und keinen vorhandenen Schlüssel haben, lesen Sie ein Zertifikat erstellen.
Um ein ECDSA-Zertifikatschlüsselpaar zu erstellen, klicken Sie auf Ein ECDSA-Zertifikatschlüsselpaarerstellen.
Kennwortgeschützte Zertifikatsschlüsselpaare werden immer erfolgreich hinzugefügt. Wenn in Builds vor 13.0 Build 79.x eine sichere Kennwortoption auf einer NetScaler-Appliance aktiviert war, wurden manchmal die kennwortgeschützten Zertifikatsschlüsselpaare nicht hinzugefügt. Die Zertifikatschlüsselkonfiguration geht jedoch verloren, wenn Sie auf einen früheren Build herunterstufen. In der NITRO-API-Antwort für Zertifikatschlüsselpaare wird die Variable
passplainanstelle der Variablenpasscryptgesendet.
Für jede SSL-Transaktion benötigt der Server ein gültiges Zertifikat und das entsprechende private und öffentliche Schlüsselpaar. Die SSL-Daten werden mit dem öffentlichen Schlüssel des Servers verschlüsselt, der über das Zertifikat des Servers verfügbar ist. Für die Entschlüsselung ist der entsprechende private Schlüssel erforderlich. Das Kennwort des privaten Schlüssels, der beim Hinzufügen eines SSL-Zertifikatsschlüsselpaars verwendet wird, wird mit einem eindeutigen Verschlüsselungsschlüssel für jede NetScaler-Appliance gespeichert.
Die ADC-Appliance lagert SSL-Transaktionen vom Server aus. Daher müssen das Zertifikat und der private Schlüssel des Servers auf der Appliance vorhanden sein, und das Zertifikat muss mit dem entsprechenden privaten Schlüssel gekoppelt werden. Dieses Zertifikatsschlüsselpaar muss an den virtuellen Server gebunden sein, der die SSL-Transaktionen verarbeitet.
Hinweis: Das Standardzertifikat auf einer NetScaler-Appliance ist 2048 Bit. In früheren Builds war das Standardzertifikat 512 Bit oder 1024 Bit. Nach dem Upgrade auf Version 11.0 müssen Sie alle Ihre alten Zertifikatsschlüsselpaare löschen und dann die Appliance neu starten "ns-", um automatisch ein 2048-Bit-Standardzertifikat zu generieren.
Sowohl das Zertifikat als auch der Schlüssel müssen sich im lokalen Speicher der NetScaler-Appliance befinden, bevor sie der Appliance hinzugefügt werden können. Wenn sich Ihr Zertifikat oder Ihre Schlüsseldatei nicht auf der Appliance befindet, laden Sie es auf die Appliance hoch, bevor Sie das Paar erstellen.
Wichtig: Zertifikate und Schlüssel werden standardmäßig im Verzeichnis /nsconfig/ssl gespeichert. Wenn Ihre Zertifikate oder Schlüssel an einem anderen Ort gespeichert sind, müssen Sie den absoluten Pfad zu den Dateien auf der NetScaler-Appliance angeben. Die NetScaler FIPS-Appliances unterstützen keine externen Schlüssel (Nicht-FIPS-Schlüssel). Auf einer FIPS-Appliance können Sie keine Schlüssel von einem lokalen Speichergerät wie einer Festplatte oder einem Flash-Speicher laden. Die FIPS-Schlüssel müssen im Hardware Security Module (HSM) der Appliance vorhanden sein.
Auf NetScaler-Appliances werden nur RSA-Schlüssel unterstützt.
Legen Sie den Benachrichtigungszeitraum fest und ermöglichen Sie dem Ablaufmonitor, vor Ablauf des Zertifikats eine Aufforderung auszustellen.
Die NetScaler-Appliance unterstützt die folgenden Eingabeformate des Zertifikats und der Privatschlüsseldateien:
- PEM — Datenschutz Enhanced Mail
- DER - Distinguished Encoding
- PFX - Austausch personenbezogener Daten
Die Software erkennt das Format automatisch. Daher müssen Sie das Format nicht mehr im inform-Parameter angeben. Wenn Sie das Format angeben (richtig oder falsch), ignoriert die Software es. Das Format des Zertifikats und der Schlüsseldatei müssen identisch sein.
Hinweis: Ein Zertifikat muss mit einem der folgenden Hash-Algorithmen signiert werden:
- MD5
- SHA-1
- SHA-224
- SHA-256
- SHA-384
- SHA-512
Eine MPX-Appliance unterstützt Zertifikate mit 512 oder mehr Bit bis zu den folgenden Größen:
- 4096-Bit-Serverzertifikat auf dem virtuellen Server
- 4096-Bit-Clientzertifikat im Dienst
- 4096-Bit-CA-Zertifikat (einschließlich Zwischen- und Stammzertifikaten)
- 4096-Bit-Zertifikat auf dem Back-End-Server
- 4096-Bit-Clientzertifikat (wenn die Clientauthentifizierung auf dem virtuellen Server aktiviert ist)
Eine virtuelle VPX-Appliance unterstützt Zertifikate mit 512 oder mehr Bit bis zu den folgenden Größen:
- 4096-Bit-Serverzertifikat auf dem virtuellen Server
- 4096-Bit-Clientzertifikat im Dienst
- 4096-Bit-CA-Zertifikat (einschließlich Zwischen- und Stammzertifikaten)
- 4096-Bit-Zertifikat auf dem Back-End-Server
- 4096-Bit-Clientzertifikat (wenn die Clientauthentifizierung auf dem virtuellen Server aktiviert ist)
Die folgende Tabelle zeigt die RSASSA-PSS-Parametersätze, die von der NetScaler-Appliance unterstützt werden. RSASSA-PSS-Algorithmen werden bei der X.509-Zertifikatspfadvalidierung unterstützt.
| OID für öffentlichen Schlüssel | Maskengenerierungsfunktion (MGF) | MGF-Digest-Funktion | Signature-Digest-Funktion | Salt-Länge |
|---|---|---|---|---|
| rsaEncryption | MGF1 | SHA-256 | SHA-256 | 32 Byte |
| rsaEncryption | MGF1 | SHA-384 | SHA-384 | 48 Byte |
| rsaEncryption | MGF1 | SHA-512 | SHA-512 | 64 Byte |
Hinweis
Eine NetScaler SDX-Appliance unterstützt Zertifikate mit 512 oder mehr Bit. Jede NetScaler VPX-Instanz, die auf der Appliance gehostet wird, unterstützt die vorherigen Zertifikatsgrößen für eine virtuelle VPX-Appliance. Wenn jedoch einer Instanz ein SSL-Chip zugewiesen ist, unterstützt diese Instanz die von einer MPX-Appliance unterstützten Zertifikatsgrößen.
Hinzufügen eines Zertifikatschlüsselpaars mit der CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um ein Zertifikatsschlüsselpaar hinzuzufügen und die Konfiguration zu überprüfen:
add ssl certKey <certkeyName> -cert <string>[(-key <string> [-password]) | -fipsKey <string>] [-inform ( DER | PEM )] [<passplain>] [-expiryMonitor ( ENABLED | DISABLED ) [-notificationPeriod <positive_integer>]]
show ssl certKey [<certkeyName>]
Beispiel:
add ssl certKey sslckey -cert server_cert.pem -key server_key.pem -password ssl -expiryMonitor ENABLED -notificationPeriod 30
Done
Note: For FIPS appliances, replace -key with -fipskey
show ssl certKey sslckey
Name: sslckey Status: Valid, Days to expiration:8418
Version: 3
Serial Number: 01
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US,ST=SJ,L=SJ,O=NS,OU=NSSSL,CN=www.root.com
Validity
Not Before: Jul 15 02:25:01 2005 GMT
Not After : Nov 30 02:25:01 2032 GMT
Subject: C=US,ST=SJ,L=SJ,O=NS,OU=NSSSL,CN=www.server.com
Public Key Algorithm: rsaEncryption
Public Key size: 2048
Done
Aktualisieren oder entfernen Sie ein Zertifikatsschlüsselpaar über die CLI
Um die Ablaufüberwachung oder den Benachrichtigungszeitraum in einem Zertifikat-Schlüsselpaar zu ändern, verwenden Sie den Befehl set ssl certkey. Um das Zertifikat oder den Schlüssel in einem Zertifikat-Schlüsselpaar zu ersetzen, verwenden Sie den Befehl update ssl certkey. Der Befehl update ssl certkey hat einen zusätzlichen Parameter zum Überschreiben der Domänenprüfung. Geben Sie für beide Befehle den Namen eines vorhandenen Zertifikat-Schlüssel-Paars ein. Um ein SSL-Zertifikat-Schlüsselpaar zu entfernen, verwenden Sie den Befehl rm ssl certkey, der nur das Argument <certkeyName> akzeptiert.
Beispiel:
set ssl certKey <certkeyName> [-expiryMonitor ( ENABLED | DISABLED )
[-notificationPeriod <positive_integer>]]
update ssl certKey <certkeyName> [-cert <string> [-password]] [-key
<string> | -fipsKey <string>] [-inform <inform>] [-noDomainCheck]
Hinzufügen oder Aktualisieren eines Zertifikatsschlüsselpaars über die GUI
-
Navigieren Sie zu Traffic Management > SSL > Zertifikate > Server.
-
Geben Sie die Werte für die folgenden Parameter ein und klicken Sie auf Installieren.
-
Name des Zertifikat-Schlüssel-Paars — Name für das Zertifikat und den privaten Schlüssel.
-
Zertifikatsdateiname — Signiertes Zertifikat, das von der Zertifizierungsstelle erhalten
-
Schlüsseldateiname — Name und optional der Pfad der privaten Schlüsseldatei, die zur Bildung des Zertifikatsschlüsselpaars verwendet wird.
-
Fehler beim Laden des Zertifikatsschlüsselpaars beim Neustart protokollieren
Nachdem eine Zertifikatsdatei oder eine private Schlüsseldatei in den NetScaler-Speicher hochgeladen wurde, werden alle Änderungen an den Quelldateien nicht übernommen, es sei denn, die Appliance wird neu gestartet. Der Neustart kann aus folgenden Gründen fehlschlagen:
- Die Zertifikatsdatei wird aktualisiert, aber die Schlüsseldatei wird nicht aktualisiert.
- Die aktualisierte Datei ist beschädigt.
- Die neue Schlüsseldatei ist passwortgeschützt.
- Das Passwort hat sich geändert.
Diese Fehler werden protokolliert /var/log/ns.log. Sie können die Datei mit dem Befehl tail -f /var/log/ns.log anzeigen.
Um diesen Fehler zu protokollieren, werden die folgenden Änderungen eingeführt:
-
Ein Digest-Attribut wird für ein Zertifikatsschlüsselpaar erstellt, wenn Sie der Appliance eine Zertifikatsdatei und eine Schlüsseldatei hinzufügen oder aktualisieren. Wenn es keine Schlüsseldatei gibt (z. B. in einer FIPS- oder einer HSM-Konfiguration), wird ein Digest nur für die Zertifikatsdatei erstellt.
Hinweis:
Der Name der Zertifikatsdatei und der Name der Datei mit dem privaten Schlüssel dürfen nur die folgenden Zeichen enthalten:
- a to z (lower case) - A to Z (upper case) - 0 to 9 (numbers) - / (forward slash) - . (period) - _ (underscore) - : (colon) - - (hyphen) -
Wenn die Appliance neu gestartet wird, wird der Digest in der Konfigurationsdatei mit dem Digest verglichen, der für das Zertifikat und die Schlüsseldatei (optional) auf der Appliance berechnet wurde. Wenn es eine Nichtübereinstimmung gibt, wird eine Fehlermeldung protokolliert.
Binden Sie das Zertifikatschlüsselpaar an den virtuellen SSL-Server
Wichtig: Verknüpfen Sie alle Zwischenzertifikate mit diesem Zertifikat, bevor Sie das Zertifikat an einen virtuellen SSL-Server binden. Informationen zum Verknüpfen von Zertifikaten finden Sie unter Erstellen einer Zertifikatkette.
Das Zertifikat, das für die Verarbeitung von SSL-Transaktionen verwendet wird, muss an den virtuellen Server gebunden sein, der die SSL-Daten empfängt. Wenn Sie über mehrere virtuelle Server verfügen, die SSL-Daten empfangen, muss an jeden von ihnen ein gültiges Zertifikatsschlüsselpaar gebunden sein.
Verwenden Sie ein gültiges, vorhandenes SSL-Zertifikat, das Sie auf die NetScaler-Appliance hochgeladen haben. Erstellen Sie alternativ zu Testzwecken Ihr eigenes SSL-Zertifikat auf der Appliance. Zwischenzertifikate, die mit einem FIPS-Schlüssel auf der Appliance erstellt wurden, können nicht an einen virtuellen SSL-Server gebunden werden.
Während des SSL-Handshakes listet der Server in der Zertifikatsanforderungsnachricht während der Clientauthentifizierung die Distinguished Names (DN) aller an den Server gebundenen Zertifizierungsstellen (CA) auf. Der Server akzeptiert nur ein Clientzertifikat aus dieser Liste. Wenn Sie nicht möchten, dass der DN-Name eines bestimmten CA-Zertifikats an den SSL-Client gesendet wird, setzen Sie das Flag skipCA. Diese Einstellung gibt an, dass der definierte Name des bestimmten Zertifizierungsstellenzertifikats nicht an den SSL-Client gesendet werden darf.
Weitere Informationen zum Erstellen eines eigenen Zertifikats finden Sie unter Zertifikate verwalten.
Hinweis: Citrix empfiehlt, nur gültige SSL-Zertifikate zu verwenden, die von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurden.
Binden eines SSL-Zertifikatsschlüsselpaars über die CLI an einen virtuellen Server
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um ein SSL-Zertifikatsschlüsselpaar an einen virtuellen Server zu binden und die Konfiguration zu überprüfen:
- bind ssl vserver <vServerName> -certkeyName <certificate-KeyPairName> -CA -skipCAName
- show ssl vserver <vServerName>
Beispiel:
bind ssl vs vs1 -certkeyName cert2 -CA -skipCAName
Done
sh ssl vs vs1
Advanced SSL configuration for VServer vs1:
DH: DISABLED
Ephemeral RSA: ENABLED Refresh Count: 0
Session Reuse: ENABLED Timeout: 120 seconds
Cipher Redirect: DISABLED
SSLv2 Redirect: DISABLED
ClearText Port: 0
Client Auth: DISABLED
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: DISABLED
OCSP Stapling: DISABLED
HSTS: DISABLED
IncludeSubDomains: NO
HSTS Max-Age: 0
SSLv2: DISABLED SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.1: DISABLED TLSv1.2: DISABLED
Push Encryption Trigger: Always
Send Close-Notify: YES
Strict Sig-Digest Check: DISABLED
ECC Curve: P_256, P_384, P_224, P_521
1) CertKey Name: cert1 CA Certificate OCSPCheck: Optional CA_Name Sent
2) CertKey Name: cert2 CA Certificate OCSPCheck: Optional CA_Name Skipped
1) Cipher Name: DEFAULT
Description: Default cipher list with encryption strength >= 128bit
Done
Trennen eines SSL-Zertifikatsschlüsselpaars von einem virtuellen Server über die CLI
Wenn Sie versuchen, ein Zertifikatsschlüsselpaar mit dem Befehl unbind ssl certKey <certkeyName> von einem virtuellen Server zu trennen, wird eine Fehlermeldung angezeigt. Der Fehler tritt auf, weil sich die Syntax des Befehls geändert hat. Geben Sie an der Eingabeaufforderung den folgenden Befehl ein:
unbind ssl vserver <vServerName> -certkeyName <string>
Beispiel:
unbind ssl vserver vssl -certkeyName sslckey
Binden Sie ein SSL-Zertifikat-Schlüsselpaar über die GUI an einen virtuellen Server
-
Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Server und öffnen Sie einen virtuellen SSL-Server. Klicken Sie in den Abschnitt Zertifikat .
-
Klicken Sie auf den Pfeil, um das Zertifikatsschlüsselpaar auszuwählen.
-
Wählen Sie das Zertifikatsschlüsselpaar aus der Liste aus.
-
Binden Sie das Zertifikatsschlüsselpaar an den virtuellen Server. Um ein Serverzertifikat als SNI-Zertifikat hinzuzufügen, wählen Sie Serverzertifikat für SNIaus.
Virtuelle SSL-Serverparameter
Stellen Sie die erweiterte SSL-Konfiguration für einen virtuellen SSL-Server ein. Sie können viele dieser Parameter auch in einem SSL-Profil festlegen. Informationen zu den Parametern, die in einem SSL-Profil festgelegt werden können, finden Sie unter SSL-Profilparameter.
Festlegen von virtuellen SSL-Serverparametern mit der CLI
Geben Sie in der Befehlszeile Folgendes ein:
set ssl vserver <vServerName>@ [-clearTextPort <port>] [-dh ( ENABLED |DISABLED ) -dhFile <string>] [-dhCount <positive_integer>][-dhKeyExpSizeLimit ( ENABLED | DISABLED )] [-eRSA ( ENABLED | DISABLED) [-eRSACount <positive_integer>]] [-sessReuse ( ENABLED | DISABLED )[-sessTimeout <positive_integer>]] [-cipherRedirect ( ENABLED | DISABLED ) [-cipherURL <URL>]] [-sslv2Redirect ( ENABLED | DISABLED )[-sslv2URL <URL>]] [-clientAuth ( ENABLED | DISABLED ) [-clientCert ( Mandatory | Optional )]] [-sslRedirect ( ENABLED | DISABLED )][-redirectPortRewrite ( ENABLED | DISABLED )] [-ssl2 ( ENABLED | DISABLED )] [-ssl3 ( ENABLED | DISABLED )] [-tls1 ( ENABLED | DISABLED )] [-tls11 ( ENABLED | DISABLED )] [-tls12 ( ENABLED | DISABLED )][-tls13 ( ENABLED | DISABLED )] [-SNIEnable ( ENABLED | DISABLED )][-ocspStapling ( ENABLED | DISABLED )] [-pushEncTrigger <pushEncTrigger>] [-sendCloseNotify ( YES | NO )] [-dtlsProfileName <string>] [-sslProfile <string>] [-HSTS ( ENABLED | DISABLED )][-maxage <positive_integer>] [-IncludeSubdomains ( YES | NO )][-strictSigDigestCheck ( ENABLED | DISABLED )] [-zeroRttEarlyData (ENABLED | DISABLED )] [-tls13SessionTicketsPerAuthContext <positive_integer>] [-dheKeyExchangeWithPsk ( YES | NO )]
Diffie-Hellman-Parameter (DH)
Um Verschlüsselungen auf der Appliance zu verwenden, die einen DH-Schlüsselaustausch zum Einrichten der SSL-Transaktion erfordern, aktivieren Sie den DH-Schlüsselaustausch auf der Appliance. Konfigurieren Sie andere Einstellungen basierend auf Ihrem Netzwerk.
Um die Verschlüsselungen aufzulisten, für die DH-Parameter über die CLI festgelegt werden müssen, geben Sie Folgendes ein: sh cipher DH.
Um die Chiffre aufzulisten, für die DH-Parameter mithilfe des Konfigurationsdienstprogramms festgelegt werden müssen, navigieren Sie zu Verkehrsverwaltung > SSL > Verschlüsselungsgruppen, und doppelklicken Sie auf DH.
Weitere Informationen zur Aktivierung des DH-Schlüsselaustauschs finden Sie unter Generieren eines Diffie-Hellman-Schlüssels (DH).
Konfigurieren von DH-Parametern mit der CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um DH-Parameter zu konfigurieren und die Konfiguration zu überprüfen:
- `set ssl vserver <vserverName> -dh <Option> -dhCount <RefreshCountValue> -filepath <string>
- show ssl vserver <vServerName>`
Beispiel:
set ssl vserver vs-server -dh ENABLED -dhFile /nsconfig/ssl/ns-server.cert -dhCount 1000
Done
show ssl vserver vs-server
Advanced SSL configuration for VServer vs-server:
DH: ENABLED
Ephemeral RSA: ENABLED Refresh Count: 1000
Session Reuse: ENABLED Timeout: 120 seconds
Cipher Redirect: DISABLED
SSLv2 Redirect: DISABLED
ClearText Port: 0
Client Auth: DISABLED
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: DISABLED
OCSP Stapling: DISABLED
HSTS: DISABLED
HSTS IncludeSubDomains: NO
HSTS Max-Age: 0
SSLv2: DISABLED SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.2: ENABLED TLSv1.2: ENABLED
1) Cipher Name: DEFAULT
Description: Predefined Cipher Alias
Done
Konfigurieren von DH-Parametern über die GUI
- Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Serverund öffnen Sie einen virtuellen Server.
- Wählen Sie im Abschnitt SSL-Parameter die Option DH Param aktivierenaus, und geben Sie einen Aktualisierungszähler und einen Dateipfad an.
Vergängliches RSA
Mit kurzlebigen RSA können Exportclients mit dem sicheren Server kommunizieren, auch wenn das Serverzertifikat keine Exportclients unterstützt (1024-Bit-Zertifikat). Wenn Sie verhindern möchten, dass Exportclients auf das sichere Webobjekt oder die sichere Ressource zugreifen, müssen Sie den kurzlebigen RSA-Schlüsselaustausch deaktivieren.
Standardmäßig ist diese Funktion auf der NetScaler-Appliance aktiviert, wobei der Aktualisierungszähler auf Null gesetzt ist (unendliche Verwendung).
Hinweis:
Der kurzlebige RSA-Schlüssel wird automatisch generiert, wenn Sie eine Exportverschlüsselung an einen SSL- oder TCP-basierten virtuellen SSL-Server oder -Dienst binden. Wenn Sie die Exportverschlüsselung entfernen, wird der eRSA-Schlüssel nicht gelöscht. Sie wird später wiederverwendet, wenn eine andere Exportverschlüsselung an einen virtuellen SSL- oder TCP-basierten SSL-Server oder -Dienst gebunden ist. Der eRSA-Schlüssel wird beim Neustart des Systems gelöscht.
Konfigurieren Sie kurzlebigen RSA über die CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um kurzlebigen RSA zu konfigurieren und die Konfiguration zu überprüfen:
set ssl vserver <vServerName> -eRSA (enabled | disabled) -eRSACount <positive_integer>
show ssl vserver <vServerName>
Beispiel:
set ssl vserver vs-server -eRSA ENABLED -eRSACount 1000
Done
show ssl vserver vs-server
Advanced SSL configuration for VServer vs-server:
DH: DISABLED
Ephemeral RSA: ENABLED Refresh Count: 1000
Session Reuse: ENABLED Timeout: 120 seconds
Cipher Redirect: DISABLED
SSLv2 Redirect: DISABLED
ClearText Port: 0
Client Auth: DISABLED
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: DISABLED
OCSP Stapling: DISABLED
HSTS: DISABLED
HSTS IncludeSubDomains: NO
HSTS Max-Age: 0
SSLv2: DISABLED SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.2: ENABLED TLSv1.2: ENABLED
1) Cipher Name: DEFAULT
Description: Predefined Cipher Alias
Done
Konfigurieren Sie kurzlebigen RSA über die GUI
- Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Serverund öffnen Sie einen virtuellen Server.
- Wählen Sie im Abschnitt SSL-Parameter die Option Ephemere RSA aktivierenaus, und geben Sie einen Aktualisierungszähler an.
Wiederverwendung der Sitzung
Für SSL-Transaktionen erfordert das Einrichten des ersten SSL-Handshakes CPU-intensive Verschlüsselungsvorgänge mit öffentlichen Schlüsseln. Die meisten Handshake-Vorgänge sind mit dem Austausch des SSL-Sitzungsschlüssels (Clientschlüsselaustauschnachricht) verbunden. Wenn eine Clientsitzung für einige Zeit im Leerlauf ist und dann wieder aufgenommen wird, wird der SSL-Handshake in der Regel erneut durchgeführt. Wenn die Sitzungswiederverwendung aktiviert ist, wird der Austausch von Sitzungsschlüsseln für vom Client empfangene Anfragen zur Sitzungswiederaufnahme vermieden.
Die Wiederverwendung von Sitzungen ist auf der NetScaler-Appliance standardmäßig aktiviert. Durch die Aktivierung dieser Funktion wird die Serverlast reduziert, die Reaktionszeit verbessert und die Anzahl der SSL-Transaktionen pro Sekunde (TPS) erhöht, die der Server unterstützen kann.
Konfigurieren der Wiederverwendung von Sitzungen über die CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um die Wiederverwendung der Sitzung zu konfigurieren und die Konfiguration zu überprüfen:
set ssl vserver <vServerName> -sessReuse ( ENABLED | DISABLED ) -sessTimeout <positive_integer>
show ssl vserver <vServerName>
Beispiel:
set ssl vserver vs-ssl -sessreuse enabled -sesstimeout 600
Done
show ssl vserver vs-ssl
Advanced SSL configuration for VServer vs-ssl:
DH: DISABLED
Ephemeral RSA: ENABLED Refresh Count: 1000
Session Reuse: ENABLED Timeout: 600 seconds
Cipher Redirect: DISABLED
SSLv2 Redirect: DISABLED
ClearText Port: 0
Client Auth: DISABLED
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: DISABLED
OCSP Stapling: DISABLED
HSTS: DISABLED
HSTS IncludeSubDomains: NO
HSTS Max-Age: 0
SSLv2: DISABLED SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.2: ENABLED TLSv1.2: ENABLED
1) CertKey Name: Auth-Cert-1 Server Certificate
1) Cipher Name: DEFAULT
Description: Predefined Cipher Alias
Done
Konfigurieren der Wiederverwendung von Sitzungen über die GUI
- Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Serverund öffnen Sie einen virtuellen Server.
- Wählen Sie im Abschnitt SSL-Parameter die Option Sitzungswiederverwendung aktivierenaus, und geben Sie eine Zeit an, zu der die Sitzung aktiv bleiben soll.
SSL-Protokolleinstellungen
Die NetScaler-Appliance unterstützt die Protokolle SSLv3, TLSv1, TLSv1.1 und TLSv1.2. Jedes dieser Protokolle kann auf der Appliance festgelegt werden, wie es für Ihre Bereitstellung und die Art der Clients erforderlich ist, die eine Verbindung zur Appliance herstellen.
Die TLS-Protokollversionen 1.0, 1.1 und 1.2 sind sicherer als ältere Versionen des TLS/SSL-Protokolls. Um jedoch Legacy-Systeme zu unterstützen, behalten viele TLS-Implementierungen die Abwärtskompatibilität mit dem SSLv3-Protokoll bei. In einem SSL-Handshake wird die höchste Protokollversion verwendet, die dem Client und dem auf der NetScaler-Appliance konfigurierten virtuellen SSL-Server gemeinsam ist.
Beim ersten Handshake-Versuch bietet ein TLS-Client die höchste Protokollversion, die er unterstützt. Wenn der Handshake fehlschlägt, bietet der Client eine niedrigere Protokollversion an. Wenn beispielsweise ein Handshake mit TLS-Version 1.1 nicht erfolgreich ist, versucht der Client, neu zu verhandeln, indem er das TLSv1.0-Protokoll anbietet. Wenn dieser Versuch nicht erfolgreich ist, versucht der Client erneut mit dem SSLv3-Protokoll. Ein “Mann in der Mitte” (MITM) -Angreifer kann den anfänglichen Handshake brechen und eine Neuverhandlung mit dem SSLv3-Protokoll auslösen und dann eine Schwachstelle in SSLv3 auszunutzen. Um solche Angriffe zu mildern, können Sie SSLv3 deaktivieren oder Neuverhandlungen mit einem heruntergestuften Protokoll nicht zulassen. Dieser Ansatz ist jedoch möglicherweise nicht praktikabel, wenn Ihre Bereitstellung Legacy-Systeme umfasst. Eine Alternative besteht darin, einen Signalisierungs-Chiffre-Suite-Wert (TLS_FALLBACK_SCSV) in der Clientanforderung zu erkennen.
Ein TLS_FALLBACK_SCSV-Wert in einer Client-Hello-Nachricht zeigt dem virtuellen Server an, dass der Client zuvor versucht hat, eine Verbindung mit einer höheren Protokollversion herzustellen, und dass die aktuelle Anforderung ein Fallback ist. Wenn der virtuelle Server diesen Wert erkennt und eine höhere Version als die vom Client angegebene unterstützt, lehnt er die Verbindung mit einer schwerwiegenden Warnung ab. Der Handshake ist erfolgreich, wenn eine der folgenden Bedingungen erfüllt ist:
- Der TLS_FALLBACK_SCSV-Wert ist nicht in der Hello-Nachricht des Clients enthalten.
- Die Protokollversion im Client Hello ist die höchste Protokollversion, die vom virtuellen Server unterstützt wird.
Konfigurieren der SSL-Protokollunterstützung über die CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um die SSL-Protokollunterstützung zu konfigurieren und die Konfiguration zu überprüfen:
set ssl vserver <vServerName> -ssl2 ( ENABLED | DISABLED ) -ssl3 ( ENABLED | DISABLED ) -tls1 ( ENABLED | DISABLED ) -tls11 ( ENABLED | DISABLED ) -tls12 ( ENABLED | DISABLED )
show ssl vserver <vServerName>
Beispiel:
set ssl vserver vs-ssl -tls11 ENABLED -tls12 ENABLED
Done
sh ssl vs vs-ssl
Advanced SSL configuration for VServer vs-ssl:
DH: DISABLED
Ephemeral RSA: ENABLED Refresh Count: 0
Session Reuse: ENABLED Timeout: 120 seconds
Cipher Redirect: DISABLED
SSLv2 Redirect: DISABLED
ClearText Port: 0
Client Auth: DISABLED
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: DISABLED
SSLv2: DISABLED SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.1: ENABLED TLSv1.2: ENABLED
Push Encryption Trigger: Always
Send Close-Notify: YES
1 bound certificate:
1) CertKey Name: mycert Server Certificate
1 configured cipher:
1) Cipher Name: DEFAULT
Description: Predefined Cipher Alias
Done
Konfigurieren der SSL-Protokollunterstützung über die GUI
- Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Serverund öffnen Sie einen virtuellen Server.
- Wählen Sie im Abschnitt SSL-Parameter ein zu aktivierendes Protokoll aus.
nah-benachrichtigen
Eine Close-Notify ist eine sichere Nachricht, die das Ende der SSL-Datenübertragung anzeigt. Eine Einstellung für eine nahe Benachrichtigung ist auf globaler Ebene erforderlich. Diese Einstellung gilt für alle virtuellen Server, Dienste und Dienstgruppen. Informationen zur globalen Einstellung finden Sie im Abschnitt “Globale SSL-Parameter” weiter unten auf dieser Seite.
Zusätzlich zur globalen Einstellung können Sie den Close-Notify-Parameter auf der Ebene des virtuellen Servers, des Dienstes oder der Dienstgruppe festlegen. Sie haben daher die Flexibilität, den Parameter für eine Entität festzulegen und ihn für eine andere Entität aufzuheben. Stellen Sie jedoch sicher, dass Sie diesen Parameter auf globaler Ebene festlegen. Andernfalls gilt die Einstellung auf Entitätsebene nicht.
Konfigurieren von Close-Notify auf Entitätsebene über die CLI
Geben Sie an der Eingabeaufforderung einen der folgenden Befehle ein, um die Funktion zum Schließen der Benachrichtigung zu konfigurieren und die Konfiguration zu überprüfen:
- Um auf der Ebene des virtuellen Servers zu konfigurieren, geben Sie Folgendes ein:
set ssl vserver <vServerName> -sendCloseNotify ( YES | NO )
show ssl vserver <vServerName>
- Um auf Service-Ebene zu konfigurieren, geben Sie Folgendes ein:
set ssl service <serviceName> -sendCloseNotify ( YES | NO )
show ssl service <serviceName>
- Um auf der Dienstgruppenebene zu konfigurieren, geben Sie Folgendes ein:
set ssl serviceGroup <serviceGroupName> -sendCloseNotify ( YES | NO )
show ssl serviceGroup <serviceGroupName>
Beispiel:
set ssl vserver sslvsvr -sendCloseNotify YES
Done
Konfigurieren Sie die Funktion zum Schließen von Benachrichtigungen auf Entitätsebene über die GUI
- Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Serverund öffnen Sie einen virtuellen Server.
- Wählen Sie im Abschnitt SSL-Parameter die Option Close-Notify sendenaus.
Globale SSL-Parameter
Die erweiterte Anpassung Ihrer SSL-Konfiguration behebt bestimmte Probleme. Sie können den Befehl set ssl parameter oder das Konfigurationsdienstprogramm verwenden, um Folgendes anzugeben:
- Für SSL-Transaktionen zu verwendende Quantengröße.
- CRL-Speichergröße.
- OCSP-Cachegröße.
- Verweigern Sie die SSL-Neuverhandlung.
- Setzen Sie das PUSH-Flag für entschlüsselte, verschlüsselte oder alle Datensätze.
- Löschen Sie Anfragen, wenn der Client den Handshake für eine Domäne initiiert und eine HTTP-Anforderung für eine andere Domäne sendet.
- Stellen Sie die Zeit ein, nach der die Verschlüsselung ausgelöst wird.
Hinweis: Die von Ihnen angegebene Zeit gilt nur, wenn Sie den
set ssl vserverBefehl oder das Konfigurationsdienstprogramm verwenden, um die timerbasierte Verschlüsselung festzulegen. - Prüfung des NDCPP-Konformitätszertifikats — Gilt, wenn die Appliance als Client fungiert (Back-End-Verbindung). Ignorieren Sie bei der Zertifikatsüberprüfung den allgemeinen Namen, wenn SAN im SSL-Zertifikat vorhanden ist.
- Ermöglichen Sie einen heterogenen Cluster von Cavium-Chip-basierten Appliances wie MPX 14000 und Intel Coleto Chip-basierten Appliances wie MPX 15000-Appliances mit einer anderen Anzahl von Paket-Engines.
- Ermöglichen Sie sichere Neuverhandlungen im Backend.
- Adaptive SSL-Verkehrskontrolle.
Konfigurieren globaler SSL-Parameter mit der CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um erweiterte SSL-Einstellungen zu konfigurieren und die Konfiguration zu überprüfen:
set ssl parameter [-quantumSize <quantumSize>] [-crlMemorySizeMB <positive_integer>] [-strictCAChecks (YES | NO)] [-sslTriggerTimeout <positive_integer>] [-sendCloseNotify (YES | NO)] [-encryptTriggerPktCount <positive_integer>] [-denySSLReneg <denySSLReneg>] [-insertionEncoding (Unicode|UTF-8)] [-ocspCacheSize <positive_integer>][- pushFlag <positive_integer>] [- dropReqWithNoHostHeader (YES | NO)] [-pushEncTriggerTimeout <positive_integer>] [-ndcppComplianceCertCheck ( YES | NO)] [-heterogeneousSSLHW (ENABLED | DISABLED )]
show ssl parameter
Beispiel:
set ssl parameter -quantumSize 8 -crlMemorySizeMB 256 -strictCAChecks no -ssltriggerTimeout 100 -sendClosenotify no -encryptTriggerPktCount 45 -denySSLReneg NONSECURE -insertionEncoding unicode -ocspCacheSize 10 -pushFlag 3 -dropReqWithNoHostHeader YES -pushEncTriggerTimeout 100 ms -ndcppComplianceCertCheck YES
Done
show ssl parameter
Advanced SSL Parameters
-----------------------
SSL quantum size : 8 KB
Max CRL memory size : 256 MB
Strict CA checks : NO
Encryption trigger timeout : 100 ms
Send Close-Notify : NO
Encryption trigger packet count : 45
Deny SSL Renegotiation : NONSECURE
Subject/Issuer Name Insertion Format : Unicode
OCSP cache size : 10 MB
Push flag : 0x3 (On every decrypted and encrypted record)
Strict Host Header check for SNI enabled SSL sessions : YES
PUSH encryption trigger timeout : 100 ms
Crypto Device Disable Limit : 0
Global undef action for control policies : CLIENTAUTH
Global undef action for data policies : NOOP
Default profile : DISABLED
SSL Insert Space in Certificate Header : YES
Disable TLS 1.1/1.2 for SSL_BRIDGE secure monitors : NO
Disable TLS 1.1/1.2 for dynamic and VPN services : NO
Software Crypto acceleration CPU Threshold : 0
Hybrid FIPS Mode : DISABLED
Signature and Hash Algorithms supported by TLS1.2 : ALL
SSL Interception Error Learning and Caching : DISABLED
SSL Interception Maximum Error Cache Memory : 0 Bytes
NDCPP Compliance Certificate Check : YES
Heterogeneous SSL HW (Cavium and Intel Based) : ENABLED
Done
Konfigurieren der NDcPP-Konformitätszertifikatprüfung über die GUI
-
Navigieren Sie zu Traffic Management > SSL und wählen Sie in der Gruppe Einstellungen die Option Erweiterte SSL-Einstellungen ändern aus.
-
Wählen Sie NDCPP-Konformitätszertifikatprüfung aus. Klicken Sie auf OK.
Unterstützung für sichere Neuverhandlungen am Backend einer NetScaler-Appliance
Hinweis: Diese Funktion wird in Version 13.0 Build 58.x und höher unterstützt. In früheren Versionen und Builds wurde nur unsichere Neuverhandlungen im Backend unterstützt.
Die Funktion wird auf den folgenden Plattformen unterstützt: • VPX • MPX-Plattformen mit N2- oder N3-Chips • Intel Coleto SSL-Chip-basierte Plattformen
Die Funktion wird auf der FIPS-Plattform noch nicht unterstützt.
Sichere Neuverhandlungen werden standardmäßig im Backend einer ADC-Appliance verweigert. Das heißt, der Parameter denySSLReneg ist auf ALL (Standard) festgelegt.
Um eine sichere Neuverhandlung im Backend zu ermöglichen, wählen Sie eine der folgenden Einstellungen für den Parameter denySSLReneg aus:
- NEIN
- FRONTEND_CLIENT
- FRONTEND_CLIENTSERVER
- NONSECURE
Ermöglichen Sie sichere Neuverhandlungen über die CLI
Geben Sie in der Befehlszeile Folgendes ein:
set ssl parameter -denySSLReneg <denySSLReneg>
Beispiel:
set ssl parameter -denySSLReneg NONSECURE
Done
sh ssl parameter
Advanced SSL Parameters
-----------------------
SSL quantum size : 8 KB
Max CRL memory size : 256 MB
Strict CA checks : NO
Encryption trigger timeout : 100 ms
Send Close-Notify : YES
Encryption trigger packet count : 45
Deny SSL Renegotiation : NONSECURE
Subject/Issuer Name Insertion Format : Unicode
OCSP cache size : 10 MB
Push flag : 0x0 (Auto)
Strict Host Header check for SNI enabled SSL sessions : NO
Match HTTP Host header with SNI : CERT
PUSH encryption trigger timeout : 1 ms
Crypto Device Disable Limit : 0
Global undef action for control policies : CLIENTAUTH
Global undef action for data policies : NOOP
Default profile : ENABLED
SSL Insert Space in Certificate Header : YES
Disable TLS 1.1/1.2 for SSL_BRIDGE secure monitors : NO
Disable TLS 1.1/1.2 for dynamic and VPN services : NO
Software Crypto acceleration CPU Threshold : 0
Hybrid FIPS Mode : DISABLED
Signature and Hash Algorithms supported by TLS1.2 : ALL
SSL Interception Error Learning and Caching : DISABLED
SSL Interception Maximum Error Cache Memory : 0 Bytes
NDCPP Compliance Certificate Check : NO
Heterogeneous SSL HW (Cavium and Intel Based) : DISABLED
Crypto Operation Queue Limit : 150%
Done
Ermöglichen Sie sichere Neuverhandlungen mit der GUI
- Navigieren Sie zu Traffic Management > SSL > Erweiterte SSL-Einstellungen ändern.
-
Legen Sie “ SSL-Neuverhandlung verweigern “ auf einen anderen Wert als ALL fest.
Adaptive SSL-Verkehrssteuerung
Hinweis: Diese Funktion wird in Version 13.0 Build 58.x und höher unterstützt.
Wenn viel Verkehr auf der Appliance empfangen wird und die Krypto-Beschleunigungskapazität voll ist, beginnt die Appliance, Verbindungen in die Warteschlange zu stellen, um sie später zu verarbeiten. Derzeit ist die Größe dieser Warteschlange auf 64 K festgelegt und die Appliance beginnt, Verbindungen zu trennen, wenn dieser Wert überschritten wird.
Benutzer können einen Wert konfigurieren, der einen Prozentsatz der tatsächlichen Kapazität darstellt. Infolgedessen löscht die Appliance neue Verbindungen, wenn die Anzahl der Elemente in der Warteschlange den Grenzwert überschreitet, der adaptiv und dynamisch berechnet wird. Dieser Ansatz steuert eingehende SSL-Verbindungen und verhindert übermäßigen Ressourcenverbrauch und andere Ausfälle, wie z. B. einen Ausfall der Lastenausgleichsüberwachung oder eine langsame Reaktion auf sichere Anwendungen auf der Appliance.
Wenn die Warteschlange leer ist, kann die Appliance weiterhin Verbindungen annehmen. Wenn die Warteschlange nicht leer ist, hat das Kryptosystem seine Kapazität erreicht und die Appliance beginnt, Verbindungen in die Warteschlange zu stellen.
Das Limit wird basierend auf folgenden Kriterien berechnet:
- Die tatsächliche Kapazität des Geräts.
- Vom Benutzer konfigurierter Wert als Prozentsatz der tatsächlichen Kapazität. Der Standardwert ist auf 150% festgelegt.
Wenn beispielsweise die tatsächliche Kapazität einer Appliance zu einem bestimmten Zeitpunkt 1000 Operationen/Sekunde beträgt und der Standardprozentsatz konfiguriert ist, beträgt der Grenzwert, nach dem die Appliance Verbindungen trennt, 1500 (150% von 1000).
So konfigurieren Sie das Limit für die Operationswarteschlange über die CLI
Geben Sie in der Befehlszeile Folgendes ein:
set ssl parameter -operationQueueLimit <positive_integer>
Limit der Warteschlange für Vorgänge - Begrenzung des Prozentsatzes der Kapazität der Warteschlange für Kryptovorgänge, ab der neue SSL-Verbindungen erst akzeptiert werden, wenn die Warteschlange reduziert wurde. Standardwert: 150. Mindestwert: 0. Maximaler Wert: 10000.
So konfigurieren Sie das Limit der Operationswarteschlange über die GUI
- Navigieren Sie zu Traffic Management > SSL.
- Klicken Sie in den Einstellungenauf Erweiterte SSL-Einstellungen ändern.
- Geben Sie einen Wert in Warteschlangenlimit für Vorgängeein. Die Standardeinstellung ist 150.
-
Klicken Sie auf OK.
Heterogene Clusterbereitstellungen
Sie können eine heterogene Clusterbereitstellung von NetScaler MPX-Appliances mit einer anderen Anzahl von Paket-Engines erstellen, indem Sie den SSL-Parameter “Heterogenous SSL HW” auf ENABLED setzen. Um beispielsweise einen Cluster aus Cavium-Chip-basierten Appliances (MPX 14000 oder ähnlich) und Intel Coleto-Chip-basierten Appliances (MPX 15000 oder ähnlich) zu bilden, aktivieren Sie den SSL-Parameter “Heterogene SSL-HW. “ Um einen Cluster von Plattformen mit demselben Chip zu bilden, behalten Sie den Standardwert (DISABLED) für diesen Parameter bei.
Hinweise:
Die folgenden Funktionen werden in einem heterogenen Cluster nicht unterstützt:
- VPX-Instanzen werden auf NetScaler SDX-Appliances gehostet.
- SSLv3-Protokoll für SSL-Entitäten wie virtuelle Server, Dienste, Dienstgruppen und interne Dienste.
- CPU-Schwellenwert für Software-Krypto-Beschleunigung (Verwendung von Hardware und Software zur Verbesserung der Verschlüsselungsleistung von ECDSA und ECDHE).
Weitere Informationen zu den Plattformen, die in einem heterogenen Cluster unterstützt werden, finden Sie unter https://docs.citrix.com/en-us/citrix-adc/current-release/clustering/support-for-heterogeneous-cluster.html.
Aktivieren eines heterogenen Clusters mit der CLI
Geben Sie in der Befehlszeile Folgendes ein:
set ssl parameter -heterogeneousSSLHW ENABLED
Ermöglichen eines heterogenen Clusters über die GUI
- Navigieren Sie zu Traffic Management > SSL und wählen Sie in der Gruppe Einstellungen die Option Erweiterte SSL-Einstellungen ändern aus.
-
Wählen Sie Heterogene SSL HW. Klicken Sie auf OK.
Push-Flag basierter Verschlüsselungsauslösemechanismus
Mit dem Verschlüsselungsauslösemechanismus, der auf dem PSH-TCP-Flag basiert, können Sie jetzt Folgendes tun:
- Führen Sie aufeinanderfolgende Pakete, in denen das PSH-Flag gesetzt ist, zu einem einzigen SSL-Datensatz zusammen oder ignorieren Sie das PSH-Flag.
- Führen Sie eine timerbasierte Verschlüsselung durch, bei der der Timeoutwert mit dem Befehl
set ssl parameter -pushEncTriggerTimeout <positive_integer>global festgelegt wird.
Konfigurieren der PUSH-Flag-basierten Verschlüsselung über die CLI
Geben Sie an der Eingabeaufforderung die folgenden Befehle ein, um die Push-Flag-basierte Verschlüsselung zu konfigurieren und die Konfiguration zu überprüfen:
set ssl vserver <vServerName> [-pushEncTrigger <pushEncTrigger>]
show ssl vserver
Beispiel:
set ssl vserver vserver1 -pushEncTrigger always
Done
sh ssl vserver vserver1
Advanced SSL configuration for VServer vserver1:
DH: DISABLED
DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: ENABLED Refresh Count: 0
Session Reuse: ENABLED Timeout: 120 seconds
Cipher Redirect: DISABLED
SSLv2 Redirect: DISABLED
ClearText Port: 0
Client Auth: DISABLED
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: DISABLED
OCSP Stapling: DISABLED
HSTS: DISABLED
HSTS IncludeSubDomains: NO
HSTS Max-Age: 0
SSLv2: DISABLED SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.1: ENABLED TLSv1.2: ENABLED TLSv1.3: DISABLED
Push Encryption Trigger: Always
Send Close-Notify: YES
Strict Sig-Digest Check: DISABLED
Zero RTT Early Data: DISABLED
DHE Key Exchange With PSK: NO
Tickets Per Authentication Context: 1
ECC Curve: P_256, P_384, P_224, P_521
1) Cipher Name: DEFAULT
Description: Default cipher list with encryption strength >= 128bit
Done
Konfigurieren der Push-Flag-basierten Verschlüsselung über die GUI
- Navigieren Sie zu Traffic Management > Load Balancing > Virtuelle Server und öffnen Sie einen virtuellen SSL-Server.
- Wählen Sie im Abschnitt SSL-Parameter in der Liste PUSH-Verschlüsselungsauslöser einen Wert aus.
Unterstützung für den TLS1.2 Signatur-Hash-Algorithmus
Die NetScaler-Appliance ist vollständig TLS1.2-Signatur-Hash-Erweiterung kompatibel.
In einem SSL-Handshake sendet ein Client eine Liste unterstützter Signatur-Hash-Algorithmen. Der Client teilt dem Server mit der Erweiterung “signature_algorithmus” mit, welche Signatur-Hash-Algorithmus-Paare in den SSL-Handshake-Nachrichten (SKE und CCV) verwendet werden könnten. Das Feld “extension_data” dieser Erweiterung enthält einen Wert “supported_signature_algorithms” in der Client-Hello Nachricht. Der SSL-Handshake wird fortgesetzt, wenn der Server einen dieser Signatur-Hash-Algorithmen unterstützt. Wenn der Server keinen dieser Algorithmen unterstützt, wird die Verbindung getrennt.
Wenn der Server ein Clientzertifikat für die Clientauthentifizierung anfordert, enthält die Zertifikatsanforderungsnachricht einen Wert “supported_signature_algorithms”. Das Clientzertifikat wird basierend auf diesem Signatur-Hash-Algorithmus ausgewählt.
Hinweis:
Die NetScaler-Appliance fungiert als Server für einen Client und als Client für den Backend-Server.
Die Appliance unterstützt nur RSA-SHA1 und RSA-SHA256 im Front-End und RSA-MD5, RSA-SHA1 und RSA-SHA256 im Backend.
Die MPX/SDX/VPX-Appliance unterstützt die folgenden Signatur-Hash-Kombinationen. Wenn auf einer SDX-Appliance ein SSL-Chip einer VPX-Instanz zugewiesen ist, gilt die Verschlüsselungsunterstützung einer MPX-Appliance. Andernfalls gilt die normale Verschlüsselungsunterstützung einer VPX-Instanz.
- Auf einer VPX-Instanz und auf einer MPX/SDX-Appliance ohne N3-Chips:
- RSA-MD5
- RSA-SHA1
- RSA-SHA224
- RSA-SHA256
- RSA-SHA384
- RSA-SHA512
- Auf einer MPX/SDX-Einheit mit N3-Chips:
- RSA-MD5
- RSA-SHA1
- RSA-SHA224
- RSA-SHA256
- RSA-SHA384
- RSA-SHA512
- ECDSA-SHA1
- ECDSA-SHA224
- ECDSA-SHA256
- ECDSA-SHA384
- ECDSA-SHA512
Standardmäßig sind alle Signatur-Hash-Algorithmen aktiviert. Sie können jedoch nur einige Signatur-Hash-Algorithmen aktivieren, indem Sie den folgenden Befehl verwenden:
set ssl parameter -sigDigestType <sigDigestType>
Parameters
sigDigestType
Signature digest algorithms supported by the appliance. The platform determines the list of algorithms supported by default.
On VPX: RSA-MD5 RSA-SHA1 RSA-SHA224 RSA-SHA256 RSA-SHA384 RSA-
SHA512
On MPX with N3 cards: RSA-MD5 RSA-SHA1 RSA-SHA224 RSA-
SHA256 RSA-SHA384 RSA-SHA512 ECDSA-SHA1 ECDSA-SHA224 ECDSA-
SHA256 ECDSA-SHA384 ECDSA-SHA512
Other MPX Platforms: RSA-MD5 RSA-SHA1 RSA-SHA224 RSA-SHA256 RSA-SHA384 RSA-
SHA512.
set ssl parameter -sigDigestType RSA-SHA224 RSA-SHA256 RSA-SHA384 RSA-SHA512
Validierung des Peer-Zertifikats
Gemäß RFC 5246 muss das Peer-Zertifikat mit einem der Signatur-Hash-Algorithmen signiert werden, die in der Client-Hello-Erweiterung enthalten sind. Sie können den Parameter strictSigDigestCheck verwenden. Abhängig von der vom Client gesendeten Signatur-Hash-Liste gibt die Appliance bei Aktivierung ein Zertifikat zurück strictSigDigestCheck, das von einem der Signatur-Hash-Algorithmen signiert ist, die in der Client-Hello-Erweiterung erwähnt werden. Wenn der Peer kein ordnungsgemäßes Zertifikat besitzt, wird die Verbindung getrennt. Wenn dieser Parameter deaktiviert ist, wird der Signatur-Hash nicht im Peer-Zertifikat geprüft.
Sie können eine strikte Signaturüberprüfung auf einem virtuellen SSL-Server und -Dienst konfigurieren. Wenn Sie diesen Parameter auf einem virtuellen SSL-Server aktivieren, muss das vom Server gesendete Serverzertifikat von einem der Signatur-Hash-Algorithmen signiert sein, die in der Client-Hello-Erweiterung aufgeführt sind. Wenn die Clientauthentifizierung aktiviert ist, muss das vom Server empfangene Clientzertifikat mit einem der Signatur-Hash-Algorithmen signiert werden, die in der vom Server gesendeten Zertifikatsanforderung aufgeführt sind.
Wenn Sie diesen Parameter in einem SSL-Dienst aktivieren, muss das vom Client empfangene Serverzertifikat von einem der Signatur-Hash-Algorithmen signiert sein, die in der Client-Hello-Erweiterung aufgeführt sind. Das Clientzertifikat muss mit einem der Signatur-Hash-Algorithmen signiert werden, die in der Zertifikatsanforderungsnachricht aufgeführt sind.
Wenn das Standardprofil aktiviert ist, können Sie es verwenden, um eine strikte Signaturüberprüfung auf einem virtuellen SSL-Server, einem SSL-Dienst und einem SSL-Profil zu konfigurieren.
Konfigurieren Sie mithilfe der CLI eine strenge Signatur-Digest-Prüfung auf einem virtuellen SSL-Server, -Dienst oder -Profil
Geben Sie in der Befehlszeile Folgendes ein:
set ssl vserver <vServerName> -strictSigDigestCheck ( ENABLED | DISABLED )
set ssl service <serviceName> -strictSigDigestCheck ( ENABLED | DISABLED )
set ssl profile <name>-strictSigDigestCheck ( ENABLED | DISABLED )
Parameters
strictSigDigestCheck
Check whether peer entity certificate is signed using one of the signature-hash algorithms supported by the NetScaler appliance.
Possible values: ENABLED, DISABLED
Default: DISABLED
Beispiel:
set ssl vserver v1 –strictSigDigestCheck Enabled
set ssl service s1 –strictSigDigestCheck Enabled
set ssl profile p1 –strictSigDigestCheck Enabled
Wichtig:
Wenn DH-, ECDHE- oder ECDSA-Verschlüsselungen auf der Appliance konfiguriert sind, muss die SKE-Nachricht mit einem der Signatur-Hashes signiert werden, die in der Clientliste gemeinsam sind, und der auf der Appliance konfigurierten Liste. Wenn kein gemeinsamer Signaturhash vorhanden ist, wird die Verbindung unterbrochen.
SSL für ADC-Admin-UI-Zugriff konfigurieren
Für den HTTPS-Zugriff auf das Konfigurationsdienstprogramm und für sichere Remoteprozeduraufrufe ist ein Zertifikatsschlüsselpaar erforderlich. Auf einer NetScaler MPX-Appliance oder einer virtuellen VPX-Appliance ist ein Zertifikatschlüsselpaar automatisch an die internen Dienste gebunden. Dieses Zertifikat wird jedoch möglicherweise von Browsern nicht als vertrauenswürdig eingestuft. Sie müssen gültige CA-Zertifikate im Browser hochladen, um die Authentifizierung ohne Fehler abzuschließen.
Konfigurieren Sie sicheres HTTPS mithilfe der CLI
Gehen Sie folgendermaßen vor, um sicheres HTTPS mithilfe der CLI zu konfigurieren:
-
Fügen Sie ein Zertifikatsschlüsselpaar hinzu.
add certkey server -cert servercert -key serverkey -
Binden Sie dieses Zertifikatschlüsselpaar an die folgenden internen Dienste.
bind ssl service nshttps-127.0.0.1-443 -certkeyname server bind ssl service nshttps-::11-443 -certkeyname server
Konfigurieren Sie sicheres HTTPS mithilfe der GUI
Gehen Sie folgendermaßen vor, um sicheres HTTPS mithilfe der GUI zu konfigurieren:
- Navigieren Sie zu Traffic Management > SSL > Zertifikate .
- Klicken Sie im Detailbereich auf Installieren.
- Geben Sie im Dialogfeld Zertifikat installieren die Zertifikatsdetails ein.
- Klicken Sie auf Installierenund dann auf Schließen.
- Navigieren Sie zu Traffic Management > Load Balancing > Services.
- Klicken Sie im Detailbereich auf der Registerkarte Aktion auf Interne Dienste.
- Wählen Sie
nshttps-127.0.0.1-443aus der Liste aus, und klicken Sie dann auf Öffnen. - Wählen Sie auf der Registerkarte SSL-Einstellungen im Bereich Verfügbar das in Schritt 4 erstellte Zertifikat aus, klicken Sie auf Binden, und klicken Sie dann auf OK.
- Wählen Sie
nshttps-::11-443aus der Liste aus, und klicken Sie dann auf Öffnen. - Wählen Sie auf der Registerkarte SSL-Einstellungen im Bereich Verfügbar das in Schritt 4 erstellte Zertifikat aus, klicken Sie auf Binden, und klicken Sie dann auf OK.
- Klicken Sie auf OK.
In diesem Artikel
- SSL aktivieren
- Konfigurieren von Diensten
- Virtuelle SSL-Serverkonfiguration
- Binden Sie Dienste an den virtuellen SSL-Server
- Konfigurieren eines virtuellen Servers mit Servernamenangabe (SNI) für das sichere Hosting mehrerer Sites
- Unterstützung für SNI im Back-End-Dienst
- Lassen Sie den Handshake für einen unbekannten Servernamen weiterlaufen
- Hinzufügen oder Aktualisieren eines Zertifikatsschlüsselpaars
- Binden Sie das Zertifikatschlüsselpaar an den virtuellen SSL-Server
- Virtuelle SSL-Serverparameter
- Globale SSL-Parameter
- SSL für ADC-Admin-UI-Zugriff konfigurieren