SSL offloading configuration

To configure SSL offloading, you must enable SSL processing on the Citrix ADC appliance and configure an SSL based virtual server. The virtual server will intercept SSL traffic, decrypt the traffic, and forward it to a service that is bound to the virtual server. To secure time-sensitive traffic, such as media streaming, you can configure a DTLS virtual server. To enable SSL offloading, you must import a valid certificate and key and bind the pair to the virtual server.

Enable SSL

To process SSL traffic, you must enable SSL processing. You can configure SSL based entities, such as virtual servers and services, without enabling SSL processing. However, they do not work until SSL processing is enabled.

Enable SSL processing by using the CLI

At the command prompt, type:

enable ns feature ssl show ns feature 

Example:

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 

Enable SSL processing by using the GUI

Navigate toSystem > Settingsand, in theModes and Featuresgroup, clickConfigure Basic Features, and clickSSL Offloading.

Configure services

On the Citrix ADC appliance, a service represents a physical server or an application on a physical server. Once configured, services are in the disabled state until the appliance can reach the physical server on the network and monitor its status.

Add a service by using the CLI

At the command prompt, type the following commands to add a service and verify the configuration:

add service  ( | )   show service  

Example:

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 

Modify or remove a service by using the CLI

To modify a service, use the set service command, which is just like using the add service command, except that you enter the name of an existing service.

To remove a service, use the rm service command, which accepts only the argument.

rm service  

Example:

rm service sslsvc 

To modify a service, use the set service command, select any parameter, and change its setting.

set service  ( | )   

Example:

set service sslsvc 198.51.100.225 SSL 443 

Configure a service by using the GUI

Navigate toTraffic Management > Load Balancing > Services, create a service, and specify the protocol as SSL.

SSL virtual server configuration

Secure sessions require establishing a connection between the client and an SSL-based virtual server on the Citrix ADC appliance. The SSL virtual server intercepts SSL traffic, decrypts it and processes it before sending it to services that are bound to the virtual server.

Note:The SSL virtual server is marked as down on the Citrix ADC appliance until a valid certificate / key pair and at least one service are bound to it. An SSL based virtual server is a load balancing virtual server of protocol type SSL or SSL_TCP. The load balancing feature must be enabled on the Citrix ADC appliance.

Add an SSL-based virtual server by using the CLI

At the command prompt, type the following commands to create an SSL-based virtual server and verify the configuration:

add lb vserver  (serviceType)   show ssl vserver  

Example:

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 

Modify or remove an SSL-based virtual server by using the CLI

修改SSL的负载平衡特性virtual server, use theset lb vservercommand. The set command is similar to theadd lb vservercommand, except that you enter the name of an existing virtual server. To modify theSSLproperties of an SSL-based virtual server, use theset ssl vservercommand. For more information, see the “SSL virtual server parameters” section later in this page.

To remove an SSL virtual server, use therm lb vservercommand, which accepts only theargument.

Configure an SSL-based virtual server by using the GUI

Navigate toTraffic Management > Load Balancing > Virtual Servers, create a virtual server, and specify the protocol as SSL.

Bind services to the SSL virtual server

The ADC appliance forwards decrypted SSL data to servers in the network. To forward data, services representing these physical servers must be bound to the virtual server that receives the SSL data.

Typically, the link between the ADC appliance and the physical server is secure. Therefore, data transfer between the appliance and the physical server does not have to be encrypted. However, you can provide end-to end-encryption by encrypting data transfer between the appliance and the server. For details, seeConfigure SSL offloading with end to end encryption.

Note:Enable the load balancing feature on the ADC appliance before you bind services to the SSL based virtual server.

Bind a service to a virtual server by using the CLI

At the command prompt, type the following commands to bind the service to the virtual server and verify the configuration:

bind lb vserver   show lb vserver  

Example:

绑定磅vserver sslvs sslsvc sh磅vserver党卫军lvs 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 

Unbind a service from a virtual server by using the CLI

At the command prompt, type the following command:

unbind lb vserver   

Example:

unbind lb vserver sslvs sslsvc Done 

Bind a service to a virtual server by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual Servers.
2. Open a virtual server and click theLoad Balancing Virtual Server Service Bindingstile under theServices and Service Groupssection.

3. In theLoad Balancing Virtual Server Service Bindingpage, clickAdd Bindingstab, clickClick to selectunderSelect Service, and select the check box next to the service to be bound.

4. ClickSelectand clickBind.

Configure a server name indication (SNI) virtual server for secure hosting of multiple sites

Virtual hosting is used by web servers to host more than one domain name with the same IP address. The appliance supports hosting of multiple secure domains by offloading SSL processing from the web servers using transparent SSL services or virtual server-based SSL offloading. However, when multiple websites are hosted on the same virtual server, the SSL handshake is completed before the expected host name is sent to the virtual server. As a result, the appliance cannot determine which certificate to present to the client after a connection is established. This problem is resolved by enabling SNI on the virtual server. SNI is a Transport Layer Security (TLS) extension used by the client to provide the host name during handshake initiation. The ADC appliance compares this host name to the common name and, if it does not match, compares it to the subject alternative name (SAN). If the name matches, the appliance presents the corresponding certificate to the client.

A wildcard SSL certificate helps enable SSL encryption on multiple subdomains if the same organization controls these domains and the second-level domain name is the same. For example, a wildcard certificate issued to a sports network using the common name “*.sports.net” can be used to secure domains, such as “login.sports.net” and “help.sports.net”. It cannot secure the “login.ftp.sports.net” domain.

Note:On an ADC appliance, only domain name, URL, and email ID DNS entries in theSANfield are compared.

You can bind multiple server certificates to a single SSL virtual server or transparent service using the -SNICert option. The virtual server or service issues these certificates if SNI is enabled on the virtual server or service. You can enable SNI at any time.

Bind multiple server certificates to a single SSL virtual server by using the CLI

At the command prompt, type the following commands to configure SNI and verify the configuration:

set ssl vserver @ [-SNIEnable ( ENABLED | DISABLED )] bind ssl vserver @ -certkeyName  -SNICert show ssl vserver  

To bind multiple server certificates to a transparent service by using the CLI, replacevserverwith service andvservernamewith service name in the preceding commands.

Note:Create the SSL service with the-clearTextPort 80option.

Bind multiple server certificates to a single SSL virtual server by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual Servers.
2. Open an SSL virtual server and, inCertificates, selectServer Certificate.
3. Add a certificate or select a certificate from the list, and clickServer Certificate for SNI.
4. InAdvanced Settings, selectSSL Parameters.
5. ClickSNI Enable.

Support for SNI on the back-end service

Note: SNI is not supported on a DTLS back-end service.

The Citrix ADC appliance supports Server Name Indication (SNI) at the back end. That is, the common name is sent as the server name in the client hello to the back-end server for successful completion of the handshake. This support helps meet federal system integrator customer security requirements. Also, SNI provides the advantage of using only one port instead of opening hundreds of different IP addresses and ports on a firewall.

Federal system integrator customer security requirements include support for Active Directory Federation Services (ADFS) 3.0 in 2012R2 and WAP servers. To meet this requirement, support for SNI at the back end on a Citrix ADC appliance is required.

Note:

For SNI to work, the server name in the client hello must match the host name configured on the back-end service that is bound to an SSL virtual server. For example, if the host name of the back-end server is www.mail.example.com, the SNI-enabled back-end service must be configured with the server name ashttps://www.mail.example.com. And this host name must match the server name in the client hello.

Support for dynamic SNI on the back-end service

The Citrix ADC appliance supports dynamic SNI on the back-end TLS connections. That is, the appliance learns the SNI in the client connection and uses it in the server-side connection. You no longer need to specify a common name in the SSL service, service group, or profile. The common name received in the SNI extension of the Client Hello message is forwarded to the back-end SSL connection.

Earlier, you had to configure static SNI on SSL services, service groups, and SSL profiles. As a result, only the configured static SNI extension was sent to the server. If a client needed to access multiple domains at the same time, the ADC appliance was not able to send the SNI received from the client to the back-end service. Instead, it sent the static common name that was configured. Now, if the back-end server is configured for multiple domains, the server can respond with the correct certificate based on the SNI received in the Client Hello message from the appliance.

Point to Note:

• SNI must be enabled on the front end and the correct SNI certificate bound to the SSL virtual server. If you don’t enable SNI on the front end, the SNI information is not passed to the back end.

• When server authentication is enabled, the server certificate is verified by the CA certificate and the common name/SAN entries in the server certificate are matched with the SNI. Therefore, the CA certificate must be bound to the service.

• Reuse of back-end connection and SSL session is based on SNI when dynamic SNI is enabled.

SSL monitors do not send SNI when dynamic SNI is enabled. For SNI based probing, attach a back-end profile on which static SNI is configured to the SSL monitors. The monitor must be configured with the same custom header as SNI.

Configure SNI on the back-end service by using the CLI

At the command prompt, type:

add service     add lb vserver     bind lb vserver   set ssl service  -SNIEnable ENABLED -commonName  set ssl profile  -SNIEnable ENABLED 

Example:

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 

Configure SNI on the back-end service by using the GUI

1. Navigate toTraffic Management > Load Balancing > Services.
2. Select an SSL service, and inAdvanced Settings, clickSSL Parameters.

3. ClickSNI Enable.

   

Configure SNI on the SSL profile by using the GUI

1. Navigate toSystem > Profiles > SSL Profile.
2. ClickAdd.

3. InBasic Settings, selectSNI Enable.

   

4. ClickOK.

Bind a secure monitor to an SNI-enabled back-end service

You can bind secure monitors of type HTTP, HTTP-ECV, TCP, or TCP-ECV to the back-end services and service groups that support SNI. However, the monitor probes do not send the SNI extension if dynamic SNI is enabled. To send SNI probes, enable static SNI in the back-end SSL profile and bind the profile to the monitor. Set the custom header in the monitor to the server name that is sent as the SNI extension in the client hello of the monitor probe.

Configure and bind a secure monitor to an SNI-enabled back-end service by using the CLI

At the command prompt, type:

add lb monitor   -secure YES add ssl profile  -sslProfileType BackEnd set lb monitor   -customHeaders  -sslprofile  set ssl profile  -sniEnable ENABLED -commonName  bind service  -monitorName  

Example:

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 

Configure and bind a secure monitor to an SNI enabled back-end service by using the GUI

1. Navigate toSystem > Profiles > SSL Profiles.
2. ClickAdd.

3. Specify a name for the profile and inSSL Profile Type, selectBackend.

   

4. Specify the common name (same as host header) and selectSNI Enable.

   

5. ClickOK.
6. Navigate toTraffic Management > Load Balancing > Monitor.
7. ClickAdd.
8. Specify a name for the monitor. InType, select HTTP, HTTP-ECV, TCP, or TCP-ECV.

9. Specify aCustom Header.

   

10. SelectSecure.
11. InSSL Profile, select the back-end SSL profile created in the preceding steps.

12. ClickCreate.

    

13. Navigate toTraffic Management > Load Balancing > Services.
14. Select an SSL service and clickEdit.

15. InMonitors, clickAdd Binding, select the monitor created in the preceding steps, and clickBind.

    

Configure and bind a secure monitor to an SNI-enabled back-end service by using the GUI

1. Navigate toTraffic Management>Load Balancing>Monitor.
2. Add a monitor of typeHTTP-ECVorTCP-ECV, and specify aCustom Header.
3. SelectCreate.
4. Navigate toTraffic Management>Load Balancing>Services.
5. Select an SSL service and clickEdit.
6. InMonitors, clickAdd Binding, select the monitor created in step 3, and clickBind.

Add or update a certificate-key pair

Notes:

If you don’t have an existing certificate and key, seeCreate a certificate.

To create an ECDSA certificate-key pair, clickCreate an ECDSA certificate-key pair.

From build 41.x, certificate names of up to 63 characters are supported.

From release 13.0 build 79.x, password protected certificate-key pairs are always added successfully. Earlier, if the strong password option was enabled on a Citrix ADC appliance, sometimes the password protected certificate-key pairs were not added. However, the certificate-key configuration is lost if you downgrade to an earlier build. Also, in the NITRO API response for certificate-key pairs, thepassplainvariable is sent instead of thepasscryptvariable.

For any SSL transaction, the server needs a valid certificate and the corresponding private and public key pair. The SSL data is encrypted with the server’s public key, which is available through the server’s certificate. Decryption requires the corresponding private key. The password of the private key used while adding an SSL certificate-key pair is saved using a unique encryption key for each Citrix ADC appliance.

The ADC appliance offloads SSL transactions from the server. Therefore, the server’s certificate and private key must be present on the appliance, and the certificate must be paired with its corresponding private key. This certificate-key pair must be bound to the virtual server that processes the SSL transactions.

Note:The default certificate on a Citrix ADC appliance is 2048 bits. In earlier builds, the default certificate was 512 bits or 1024 bits. After upgrading to release 11.0, you must delete all your old certificate-key pairs starting with"ns-", and then restart the appliance to automatically generate a 2048-bit default certificate.

证书和密钥必须在当地storage on the Citrix ADC appliance before they can be added to the appliance. If your certificate or key file is not on the appliance, upload it to the appliance before you create the pair.

Important:Certificates and keys are stored in the /nsconfig/ssl directory by default. If your certificates or keys are stored in any other location, you must provide the absolute path to the files on the Citrix ADC appliance. The Citrix ADC FIPS appliances do not support external keys (non-FIPS keys). On a FIPS appliance, you cannot load keys from a local storage device such as a hard disk or flash memory. The FIPS keys must be present in the Hardware Security Module (HSM) of the appliance.

Only RSA keys are supported on Citrix ADC appliances.

Set the notification period and enable the expiry monitor to issue a prompt before the certificate expires.

The Citrix ADC appliance supports the following input formats of the certificate and the private-key files:

• PEM - Privacy Enhanced Mail
• DER - Distinguished Encoding Rule
• PFX - Personal Information Exchange

The software automatically detects the format. Therefore, you are no longer required to specify the format in the inform parameter. If you do specify the format (correct or incorrect), the software ignores it. The format of the certificate and the key file must be the same.

Note:A certificate must be signed by using one of the following hash algorithms:

• MD5
• SHA-1
• SHA-224
• SHA-256
• SHA-384
• SHA-512

An MPX appliance supports certificates of 512 or more bits, up to the following sizes:

• 4096-bit server certificate on the virtual server
• 4096-bit client certificate on the service
• 4096-bit CA certificate (includes intermediate and root certificates)
• 4096-bit certificate on the back-end server
• 4096-bit client certificate (if client authentication is enabled on the virtual server)

A VPX virtual appliance supports certificates of 512 or more bits, up to the following sizes:

• 4096-bit server certificate on the virtual server
• 4096-bit client certificate on the service
• 4096-bit CA certificate (includes intermediate and root certificates)
• 4096-bit certificate on the back-end server
• 4096-bit client certificate (if client authentication is enabled on the virtual server)

Note

A Citrix ADC SDX appliance supports certificates of 512 or more bits. Each Citrix ADC VPX instance hosted on the appliance supports the preceding certificate sizes for a VPX virtual appliance. However, if an SSL chip is assigned to an instance, that instance supports the certificate sizes supported by an MPX appliance.

Add a certificate-key pair by using the CLI

At the command prompt, type the following commands to add a certificate-key pair and verify the configuration:

添加ssl certKey < certkeyName > cert <字符串>[(关键 [-password]) | -fipsKey ] [-inform ( DER | PEM )] [] [-expiryMonitor ( ENABLED | DISABLED ) [-notificationPeriod ]] show ssl certKey [] 

Example:

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 

Update or remove a certificate-key pair by using the CLI

To modify the expiry monitor or notification period in a certificate-key pair, use theset ssl certkeycommand. To replace the certificate or key in a certificate-key pair, use theupdate ssl certkeycommand. Theupdate ssl certkeycommand has an extra parameter for overriding the domain check. For both commands, enter the name of an existing certificate-key pair. To remove an SSL certificate-key pair, use therm ssl certkeycommand, which accepts only theargument.

Example:

set ssl certKey  [-expiryMonitor ( ENABLED | DISABLED ) [-notificationPeriod ]] update ssl certKey  [-cert  [-password]] [-key  | -fipsKey ] [-inform ] [-noDomainCheck] 

Add or update a certificate-key pair by using the GUI

1. Navigate toTraffic Management > SSL > Certificates > Server.

   

2. Enter the values for the following parameters and clickInstall.

   • Certificate-Key Pair Name - Name for the certificate and private-key pair.

   • Certificate File Name - Signed certificate received from the certificate authority.

   • Key File Name - Name of and, optionally, path to the private-key file that is used to form the certificate-key pair.

   

Bind the certificate-key pair to the SSL virtual server

Important: Link any intermediate certificates to this certificate before binding the certificate to an SSL virtual server. For information about linking certificates, seeCreate a chain of certificates.

The certificate being used for processing SSL transactions must be bound to the virtual server that receives the SSL data. If you have multiple virtual servers receiving SSL data, a valid certificate-key pair must be bound to each of them.

Use a valid, existing SSL certificate that you have uploaded to the Citrix ADC appliance. As an alternative for testing purposes, create your own SSL certificate on the appliance. Intermediate certificates created by using a FIPS key on the appliance cannot be bound to an SSL virtual server.

During the SSL handshake, in the certificate request message during client authentication, the server lists the distinguished names (DN) of all the certificate authorities (CA) bound to the server. The server accepts a client certificate only from this list. If you do not want the DN name of a specific CA certificate to be sent to the SSL client, set theskipCAflag. This setting indicates that the particular CA certificate’s distinguished name must not be sent to the SSL client.

For details on how to create your own certificate, seeManaging Certificates.

Note: Citrix recommends that you use only valid SSL certificates issued by a trusted certificate authority.

Bind an SSL certificate-key pair to a virtual server by using the CLI

At the command prompt, type the following commands to bind an SSL certificate-key pair to a virtual server and verify the configuration:

- bind ssl vserver  -certkeyName  -CA -skipCAName - show ssl vserver  

Example:

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 

Unbind an SSL certificate-key pair from a virtual server by using the CLI

If you try to unbind a certificate-key pair from a virtual server by using theunbind ssl certKey command, an error message appears. The error appears because the syntax of the command has changed. At the command prompt, type the following command:

解开ssl vserver < vServerName > -certkeyName < string> 

Example:

unbind ssl vserver vssl -certkeyName sslckey 

Bind an SSL certificate-key pair to a virtual server by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual Serversand open an SSL virtual server. Click inside theCertificatesection.

   

2. Click the arrow to select the certificate-key pair.

   

3. Select the certificate-key pair from the list.

   

4. Bind the certificate-key pair to the virtual server. To add a server certificate as an SNI certificate, selectServer Certificate for SNI.

   

SSL virtual server parameters

Set the advanced SSL configuration for an SSL virtual server. You can also set many of these parameters in an SSL profile. For information about the parameters that can be set in an SSL profile, seeSSL profile parameters.

Set SSL virtual server parameters by using the CLI

At the command prompt, type:

set ssl vserver @ [-clearTextPort ] [-dh ( ENABLED |DISABLED ) -dhFile ] [-dhCount ][-dhKeyExpSizeLimit ( ENABLED | DISABLED )] [-eRSA ( ENABLED | DISABLED) [-eRSACount ]] [-sessReuse ( ENABLED | DISABLED )[-sessTimeout ]] [-cipherRedirect ( ENABLED | DISABLED ) [-cipherURL ]] [-sslv2Redirect ( ENABLED | DISABLED )[-sslv2URL ]] [-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 ] [-sendCloseNotify ( YES | NO )] [-dtlsProfileName ] [-sslProfile ] [-HSTS ( ENABLED | DISABLED )][-maxage ] [-IncludeSubdomains ( YES | NO )][-strictSigDigestCheck ( ENABLED | DISABLED )] [-zeroRttEarlyData (ENABLED | DISABLED )] [-tls13SessionTicketsPerAuthContext ] [-dheKeyExchangeWithPsk ( YES | NO )] 

Diffie-Hellman (DH) parameters

使用密码的设备上需要一个DHkey exchange to set up the SSL transaction, enable DH key exchange on the appliance. Configure other settings based on your network.

To list the ciphers for which DH parameters must be set by using the CLI, type: sh cipher DH.

To list the ciphers for which DH parameters must be set by using the configuration utility, navigate toTraffic Management > SSL > Cipher Groups, and double-clickDH.

For details on how to enable DH key exchange, seeGenerate a Diffie-Hellman (DH) key.

Configure DH parameters by using the CLI

At the command prompt, type the following commands to configure DH parameters and verify the configuration:

- `set ssl vserver  -dh  -dhCount  -filepath  - show ssl vserver ` 

Example:

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 

Configure DH parameters by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual Servers, and open a virtual server.
2. In theSSL Parameterssection, selectEnable DH Param, and specify a refresh count and file path.

Ephemeral RSA

Ephemeral RSA allows export clients to communicate with the secure server even if the server certificate does not support export clients (1024-bit certificate). If you want to prevent export clients from accessing the secure web object or resource, you need to disable ephemeral RSA key exchange.

By default, this feature is enabled on the Citrix ADC appliance, with the refresh count set to zero (infinite use).

Note:

The ephemeral RSA key is automatically generated when you bind an export cipher to an SSL or TCP-based SSL virtual server or service. When you remove the export cipher, the eRSA key is not deleted. It is reused later when another export cipher is bound to an SSL or TCP-based SSL virtual server or service. The eRSA key is deleted when the system restarts.

Configure ephemeral RSA by using the CLI

At the command prompt, type the following commands to configure ephemeral RSA and verify the configuration:

set ssl vserver  -eRSA (enabled | disabled) -eRSACount  show ssl vserver  

Example:

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 

Configure ephemeral RSA by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual Servers, and open a virtual server.
2. In theSSL Parameterssection, selectEnable Ephemeral RSA, and specify a refresh count.

Session reuse

For SSL transactions, establishing the initial SSL handshake requires CPU-intensive public key encryption operations. Most handshake operations are associated with the exchange of the SSL session key (client key exchange message). When a client session is idle for some time and is then resumed, the SSL handshake is typically conducted all over again. With session reuse enabled, session key exchange is avoided for session resumption requests received from the client.

Session reuse is enabled on the Citrix ADC appliance by default. Enabling this feature reduces server load, improves response time, and increases the number of SSL transactions per second (TPS) that the server can support.

Configure session reuse by using the CLI

At the command prompt, type the following commands to configure session reuse and verify the configuration:

set ssl vserver  -sessReuse ( ENABLED | DISABLED ) -sessTimeout  show ssl vserver  

Example:

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 

Configure session reuse by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual Servers, and open a virtual server.
2. In theSSL Parameterssection, selectEnable Session Reuse, and specify a time for which to keep the session active.

SSL protocol settings

The Citrix ADC appliance supports the SSLv3, TLSv1, TLSv1.1, and TLSv1.2 protocols. Each of these protocols can be set on the appliance as required by your deployment and the type of clients that connect to the appliance.

TLS协议版本1.0,1.1,和1.2 secure than older versions of the TLS/SSL protocol. However, to support legacy systems, many TLS implementations maintain backward compatibility with the SSLv3 protocol. In an SSL handshake, the highest protocol version common to the client and the SSL virtual server configured on the Citrix ADC appliance is used.

In the first handshake attempt, a TLS client offers the highest protocol version that it supports. If the handshake fails, the client offers a lower protocol version. For example, if a handshake with TLS version 1.1 is not successful, the client attempts to renegotiate by offering the TLSv1.0 protocol. If that attempt is unsuccessful, the client reattempts with the SSLv3 protocol. A “man in the middle” (MITM) attacker can break the initial handshake and trigger renegotiation with the SSLv3 protocol, and then exploit a vulnerability in SSLv3. To mitigate such attacks, you can disable SSLv3 or not allow renegotiation using a downgraded protocol. However, this approach might not be practical if your deployment includes legacy systems. An alternative is to recognize a signaling cipher suite value (TLS_FALLBACK_SCSV) in the client request.

A TLS_FALLBACK_SCSV value in a client hello message indicates to the virtual server that the client has previously attempted to connect with a higher protocol version and that the current request is a fallback. If the virtual server detects this value, and it supports a version higher than the one indicated by the client, it rejects the connection with a fatal alert. The handshake succeeds if one of the following conditions is met:

• TLS_FALLBACK_SCSV value is not included in the client hello message.
• 协议版本的客户端你好你好ghest protocol version supported by the virtual server.

Configure SSL protocol support by using the CLI

At the command prompt, type the following commands to configure SSL protocol support and verify the configuration:

set ssl vserver  -ssl2 ( ENABLED | DISABLED ) -ssl3 ( ENABLED | DISABLED ) -tls1 ( ENABLED | DISABLED ) -tls11 ( ENABLED | DISABLED ) -tls12 ( ENABLED | DISABLED ) show ssl vserver  

Example:

启用ssl设置vserver vs-ssl -tls11 -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 

Configure SSL protocol support by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual Servers, and open a virtual server.
2. In theSSL Parameterssection, select a protocol to enable.

Close-notify

A close-notify is a secure message that indicates the end of SSL data transmission. A close-notify setting is required at the global level. This setting applies to all virtual servers, services, and service groups. For information about the global setting, see the “Global SSL parameters” section later in this page.

In addition to the global setting, you can set the close-notify parameter at the virtual server, service, or service group level. You therefore have the flexibility of setting the parameter for one entity and unsetting it for another entity. However, make sure that you set this parameter at the global level. Otherwise, the setting at the entity level does not apply.

Configure close-notify at the entity level by using the CLI

At the command prompt, type any of the following commands to configure the close-notify feature and verify the configuration:

1. To configure at the virtual server level, type:

set ssl vserver  -sendCloseNotify ( YES | NO ) show ssl vserver  

1. To configure at the service level, type:

set ssl service  -sendCloseNotify ( YES | NO ) show ssl service  

1. To configure at the service group level, type:

set ssl serviceGroup  -sendCloseNotify ( YES | NO ) show ssl serviceGroup  

Example:

set ssl vserver sslvsvr -sendCloseNotify YES Done 

Configure the close-notify feature at the entity level by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual Servers, and open a virtual server.
2. In theSSL Parameterssection, selectSend Close-Notify.

Global SSL parameters

Advanced customization of your SSL configuration addresses specific issues. You can use theset ssl parametercommand or the configuration utility to specify the following:

• 量子尺寸是我们ed for SSL transactions.
• CRL memory size.
• OCSP cache size.
• Deny SSL renegotiation.
• Set the PUSH flag for decrypted, encrypted, or all records.
• Drop requests if the client initiates the handshake for one domain and sends an HTTP request for another domain.
• Set the time after which encryption is triggered. Note: The time that you specify applies only if you use theset ssl vservercommand or the configuration utility to set timer-based encryption.
• NDCPP compliance certificate check – Applies when the appliance acts a client (back-end connection). During certificate verification, ignore the common name if SAN is present in the SSL certificate.
• 使异构集群Cavium芯片基地d appliances, such as MPX 14000, and Intel Coleto chip based appliances, such as MPX 15000 appliances with a different number of packet engines. (Support added in release 13.0 build 47.x).
• Enable secure renegotiation at the back end (Support added from release 1.0 build 58.x).
• Adaptive SSL traffic control (Support added in release 13.0 build 58.x).

Configure global SSL parameters by using the CLI

At the command prompt, type the following commands to configure advanced SSL settings and verify the configuration:

set ssl parameter [-quantumSize ] [-crlMemorySizeMB ] [-strictCAChecks (YES | NO)] [-sslTriggerTimeout ] [-sendCloseNotify (YES | NO)] [-encryptTriggerPktCount ] [-denySSLReneg ] [-insertionEncoding (Unicode|UTF-8)] [-ocspCacheSize ][- pushFlag ] [- dropReqWithNoHostHeader (YES | NO)] [-pushEncTriggerTimeout ] [-ndcppComplianceCertCheck ( YES | NO)] [-heterogeneousSSLHW (ENABLED | DISABLED )] show ssl parameter 

Example:

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 

Configure NDcPP compliance certificate check by using the GUI

1. Navigate toTraffic Management > SSLand, in theSettingsgroup, selectChange advanced SSL settings.

   

2. SelectNDCPP Compliance Certificate Check. ClickOK.

   

Support for secure renegotiation at the back end of a Citrix ADC appliance

Note:This feature is supported in release 13.0 build 58.x and later. In earlier releases and builds, only non-secure renegotiation was supported on the back end.

The feature is supported on the following platforms: • VPX • MPX platforms containing N2 or N3 chips • Intel Coleto SSL chip based platforms

The feature is not yet supported on the FIPS platform.

Secure renegotiation is denied by default on the back end of an ADC appliance. That is, thedenySSLRenegparameter is set to ALL (default).

To allow secure renegotiation on the back end, select from one of the following settings for thedenySSLRenegparameter:

• NO
• FRONTEND_CLIENT
• FRONTEND_CLIENTSERVER
• NONSECURE

Enable secure renegotiation by using the CLI

At the command prompt, type:

set ssl parameter -denySSLReneg

Example:

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 

Enable secure renegotiation by using the GUI

1. Navigate toTraffic Management > SSL > Change advanced SSL settings.

2. SetDeny SSL Renegotiationto any value other than ALL.

   

Adaptive SSL traffic control

Note:This feature is supported in release 13.0 build 58.x and later.

When high traffic is received on the appliance and the crypto acceleration capacity is full, the appliance starts queuing connections to process later. Currently, the size of this queue is fixed at 64 K and the appliance starts dropping connections if this value is exceeded.

From release 13.0 build 58.x, the user can configure a value that is a percentage of the actual capacity. With this enhancement, the appliance drops new connections if the number of elements in the queue is greater than the limit that is adaptively and dynamically calculated. This approach controls incoming SSL connections and prevents excessive resource consumption and other failures, such as load balancing monitoring failure or slow response to secure applications, on the appliance.

If the queue is empty, the appliance can continue to accept connections. If the queue is not empty, the crypto system has reached its capacity and the appliance starts queuing connections.

The limit is calculated based on:

• The actual capacity of the appliance.
• Value configured by the user as a percentage of the actual capacity. Default value is set to 150%.

For example, if the actual capacity of an appliance is 1000 operations/second at a given time and the default percentage is configured, the limit after which the appliance drops connections is 1500 (150% of 1000).

To configure the operation queue limit by using the CLI

At the command prompt, type:

set ssl parameter -operationQueueLimit

Operation Queue Limit- Limit in percentage of capacity of the crypto operations queue beyond which new SSL connections are not accepted until the queue is reduced. Default value: 150. Minimum value: 0. Maximum value: 10000.

To configure the operation queue limit by using the GUI

1. Navigate toTraffic Management > SSL.
2. InSettings, clickChange advanced SSL settings.
3. Type a value inOperation Queue Limit. Default is 150.

4. ClickOK.

   

Heterogeneous cluster deployments

From release 13.0 build 47.x, you can form a heterogeneous cluster deployment of Citrix ADC MPX appliances with a different number of packet engines by setting the SSL parameter “Heterogeneous SSL HW” to ENABLED. For example, to form a cluster of Cavium chip based appliances (MPX 14000 or similar) and Intel Coleto chip based appliances (MPX 15000 or similar), enable the SSL parameter “Heterogeneous SSL HW.” To form a cluster of platforms using the same chip, keep the default value (DISABLED) for this parameter.

Notes:

The following features are not supported in a heterogeneous cluster:

• VPX instances hosted on Citrix ADC SDX appliances.
• SSLv3 protocol on SSL entities, such as virtual server, services, service group, and internal services.
• Software crypto acceleration CPU threshold (using hardware and software to improve ECDSA and ECDHE cipher performance).

For more information about the platforms supported in a heterogeneous cluster, seehttps://docs.citrix.com/en-us/citrix-adc/13/clustering/support-for-heterogeneous-cluster.html.

Enable a heterogeneous cluster using the CLI

At the command prompt, type:

set ssl parameter -heterogeneousSSLHW ENABLED

Enable a heterogeneous cluster using the GUI

1. Navigate toTraffic Management > SSLand, in theSettingsgroup, selectChange advanced SSL settings.

2. SelectHeterogeneous SSL HW. ClickOK.

   

PUSH flag based encryption trigger mechanism

The encryption trigger mechanism that is based on the PSH TCP flag now enables you to do the following:

• Merge consecutive packets in which the PSH flag is set into a single SSL record, or ignore the PSH flag.
• Perform timer-based encryption, in which the time-out value is set globally by using theset ssl parameter -pushEncTriggerTimeout command.

Configure PUSH flag-based encryption by using the CLI

At the command prompt, type the following commands to configure PUSH flag-based encryption and verify the configuration:

set ssl vserver  [-pushEncTrigger ] show ssl vserver 

Example:

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 

Configure PUSH flag-based encryption by using the GUI

1. Navigate toTraffic Management > Load Balancing > Virtual serversand open an SSL virtual server.
2. In theSSL Parameterssection, from thePUSH Encryption Triggerlist, select a value.

Support for TLS1.2 signature hash algorithm

The Citrix ADC appliance is completely TLS1.2 signature hash extension compliant.

在SSL握手,一个客户端发送增刊的列表orted signature hash algorithms. The client indicates to the server which signature hash algorithm pairs might be used in the SSL handshake messages (SKE and CCV) by using the “signature_algorithms” extension. The “extension_data” field of this extension contains a “supported_signature_algorithms” value in the Client Hello message. The SSL handshake proceeds if the server supports one of these signature hash algorithms. If the server does not support any of these algorithms, the connection is dropped.

Similarly, if the server requests a client certificate for client authentication, the Certificate Request message contains a “supported_signature_algorithms” value. The client certificate is selected based on this signature hash algorithm.

Note:

The Citrix ADC appliance acts as a server to a client and as a client to the back-end server.

The appliance supports only RSA-SHA1 and RSA-SHA256 on the front end, and RSA-MD5, RSA-SHA1, and RSA-SHA256 on the back end.

The MPX/SDX/VPX appliance supports the following signature hash combinations. On an SDX appliance, if an SSL chip is assigned to a VPX instance, the cipher support of an MPX appliance applies. Otherwise, the normal cipher support of a VPX instance applies.

• On a VPX instance and on an MPX/SDX appliance without N3 chips:
  • RSA-MD5
  • RSA-SHA1
  • RSA-SHA224
  • RSA-SHA256
  • RSA-SHA384
  • RSA-SHA512
• On an MPX/SDX appliance with N3 chips:
  • RSA-MD5
  • RSA-SHA1
  • RSA-SHA224
  • RSA-SHA256
  • RSA-SHA384
  • RSA-SHA512
  • ECDSA-SHA1
  • ECDSA-SHA224
  • ECDSA-SHA256
  • ECDSA-SHA384
  • ECDSA-SHA512

By default, all the signature hash algorithms are enabled. However, you can enable only a few signature hash algorithms by using the following command:

set ssl parameter -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 

Validate the peer certificate

According to RFC 5246, the peer certificate must be signed using one of the signature hash algorithms included in the Client Hello extension. You can use thestrictSigDigestCheckparameter. Depending on the signature hash list sent by the client, if you enablestrictSigDigestCheck, the appliance returns a certificate signed by one of the signature hash algorithms mentioned in the Client Hello extension. If the peer does not have a proper certificate, the connection is dropped. If this parameter is disabled, the signature hash is not checked in the peer certificate.

You can configure a strict signature digest check on an SSL virtual server and service. If you enable this parameter on an SSL virtual server, the server certificate sent by the server must be signed by one of the signature hash algorithms listed in the Client Hello extension. If client authentication is enabled, then the client certificate received by the server must be signed using one of the signature hash algorithms listed in the certificate request sent by the server.

If you enable this parameter on an SSL service, the server certificate received by the client must be signed by one of the signature hash algorithms listed in the Client Hello extension. The client certificate must be signed using one of the signature hash algorithms listed in the certificate request message.

If the default profile is enabled, you can use it to configure a strict signature digest check on an SSL virtual server, SSL service, and SSL profile.

消化检查SSL配置严格的签名virtual server, service, or profile by using the CLI

At the command prompt, type:

set ssl vserver  -strictSigDigestCheck ( ENABLED | DISABLED ) set ssl service  -strictSigDigestCheck ( ENABLED | DISABLED ) set ssl profile -strictSigDigestCheck ( ENABLED | DISABLED ) Parameters strictSigDigestCheck Check whether peer entity certificate is signed using one of the signature-hash algorithms supported by the Citrix ADC appliance. Possible values: ENABLED, DISABLED Default: DISABLED 

Example:

set ssl vserver v1 –strictSigDigestCheck Enabled set ssl service s1 –strictSigDigestCheck Enabled set ssl profile p1 –strictSigDigestCheck Enabled 

Important:

If DH, ECDHE, or ECDSA ciphers are configured on the appliance, the SKE message must be signed using one of the signature-hashes common to the client list and the list configured on the appliance. If there is no common signature hash, the connection is dropped.