Subhojit Goswami

Author: Subhojit Goswami, Satyam Mehrotra and Lahari Panga Introduction to Profiles SSL/TLS is a core tenet of NetScaler which caters to the ever-changing security landscape of application delivery for any organization. NetScaler has a robust SSL/TLS feature stack with some of the core features such as TLS Offload, etc. To leverage the feature stack, one needs to configure the Netscaler. Configuring the NetScaler can be a tedious and time-consuming process, as to cater to any enterprise organization, one needs to configure innumerable entities such as ‘n’ number of virtual servers, services, internal services, etc. Most of the time, the vast majority of these entities will have identical settings configured and if any kind of change is required then one needs to go to each of those entities and make the necessary changes in the configured setting. Hence, it creates a lot of repetitive processes which is not good for user experience. To simplify the above issue, Netscaler introduced an entity known as ‘Profile’. With the ‘Profile’ entity, one can simply edit the settings on the Profile itself and then bind the Profile to all the other entities that have identical settings, thus mitigating the repetitive and time–consuming processes. Now, this Profile entity is extended to many other feature stacks such as TCP, SSL, HTTP, etc. In this article, we will focus solely on the SSL Profile. Currently, there are two types of SSL Profile: Legacy SSL Profile Enhanced/Default SSL Profile Both these Profiles solve the inherent issue of making identical SSL setting changes via the entity-specific SSL parameter setting, where one has to go and make the necessary changes on every entity like virtual servers, services, etc. Deep dive into Legacy and Enhanced/Default SSL Profile Let's take a closer look at the Legacy SSL Profile. The Legacy SSL Profile inherits all the parameters of the SSL context entities (virtual servers/ services/ service groups/internal services of type SSL) into the profile. Bindings such as ECC curves and Ciphers are left out of the profile and are still part of the original SSL contexts. Users can set the SSL profile on the SSL context entities by using a set command. For example: set ssl vserver <name> -sslprofile <name of ssl profile> If this command is successful, then the parameter values are taken from the SSL Profile instead of the SSL vserver. As pointed out earlier, ECC curves and ciphers are still kept with vserver (in this example). This is how a show command output will look like: sh ssl vserver v1 Advanced SSL configuration for VServer v1: Profile Name :ns_default_ssl_profile_frontend ECC Curve: P_256, P_384, P_224, P_521 1) Cipher Name: DEFAULT Description: Default cipher list with encryption strength >= 128 bit To mitigate the above-mentioned limitations of Legacy SSL Profile, Enhanced/Default SSL Profile can be leveraged. A Enhanced/Default SSL Profile contains all the necessary settings an SSL context can have, and it also includes ECC curve and cipher bindings. To enable enhanced SSL Profile, one can run the following command: set ssl parameter -defaultProfile ENABLED When the user runs this command, all the profiles present in the system get converted to Enhanced SSL profile. The command for setting profile on vserver remains the same as before: set ssl vserver <name> -sslprofile <name of ssl profile> Show output will look like this: > sh ssl vserver v1 Advanced SSL configuration for VServer v1: Profile Name :ns_default_ssl_profile_frontend Done As seen here, since the ECC and cipher bindings are also a part of the profile, we do not see them as a part of sh ssl vserver output. To see the details of a profile, we can run show ssl profile <name> command. Enhanced SSL profile is a powerful concept, and it takes all the advantages of profile infrastructure. NetScaler also provides a few default ssl profiles for use. Here is a list of default ssl profiles: ns_default_ssl_profile_backend ns_default_ssl_profile_frontend ns_default_ssl_profile_internal_frontend_service ns_default_ssl_profile_secure_frontend ns_default_ssl_profile_quic_frontend ns_default_ssl_profile_secure_frontend_cloud The ns_default_ssl_profile_frontend and ns_default_ssl_profile_backend are the most important SSL profiles. When a user enables default SSL profile, all the front-end entities like virtual servers get attached to ns_default_ssl_profile_frontend profile and the backend entities like service and service group get attached to ns_default_ssl_profile_backend profile. These two profiles are editable, and the user is allowed to make modifications. One significant thing that a user needs to make a note of is that once the Enhanced Profile is enabled (set ssl parameter -defaultProfile ENABLED) it cannot be undone. The only way to revert is to do a clear configuration on NetScaler. Need for the migration from Legacy to Enhanced/Default SSL Profile Along with overcoming the limitations posed by the Legacy SSL Profile with the inception of Enhanced/Default SSL Profile, there is another major factor that makes Enhanced/Default SSL Profile the latest and the greatest of the SSL Profile infrastructure, i.e., all the new features are/will only be available on Enhanced/Default SSL Profile. So, for one to leverage the SSL/TLS stack to its fullest and utilize the latest features, it is the hour of need for one to migrate from the Legacy SSL Profile to the Enhanced/Default SSL Profile. The following are some of the TLS features that are available only in an Enhanced/Default SSL Profile: TLSv1.3 SSL Interception Session Ticket Allow Extended Master Secret ALPN Protocol Use only bound CA certificates allowUnknownSNI Migrating from the Legacy SSL Profile to the Enhanced/Default SSL Profile can be a very tedious and time-consuming process, as there can be n number of Legacy SSL Profiles applied to n number of entities. So, to ease the pain of the user, NetScaler came up with an SSL Profile Converter Tool for seamless migration, taking the overarching process pain from the user’s hands. We are also pleased to state that this tool has now been integrated with the NetScaler GUI which makes it even simpler for a user to convert, just with a click of a button. But first, let’s see how the tool works under the hood: The tool takes a given NetScaler configuration file and scans it. Post scanning it intelligently segregates entities with identical settings like ‘n’ number of vservers having Legacy Profiles with identical settings, etc., it also takes care of entity-specific settings, i.e., entities having no Profile. Once the segregation has been done, the tool generates the corresponding Enhanced/Default SSL Profile for each cohort and finally writes the changes into an output batch file. Thus, completely automating the migration process and improving the user experience. Now let’s take a look at the steps needed to be adhered to by a user from the NetScaler ADC GUI perspective to use this particular tool: The tool resides in: Traffic Management > SSL > Tools > SSL Profile Converter. First and foremost, the user has to save the NetScaler configuration. After that one needs to click on the checkbox indicating that the configuration has been saved, then click on the “Run SSL Profile Conversion” button which converts and produces a batch file with all the Enhanced SSL Profiles in it. Output file location when using admin partitions and running the script from CLI: /nsconfig/partitions/<partition_name>/sslprofile_cmds.txt. Output file location when using the default partition and running the script from CLI or GUI: /nsconfig/sslprofile_cmds.txt. Once the conversion has been successful, the user needs to review the output file, which can be done instantaneously by clicking on the “View” button, or by clicking on the “ Download” button to download and review it later. Once the reviewing is done, one can simply enable the Default SSL Profile first with the following command: set ssl parameter -defaultProfile ENABLED And then batch the output file. Thus, having a seamless transition. In this way, a user can seamlessly transition from SSL Legacy Profile/No Profile to Enhanced/Default SSL Profile with just the click of a button. THANK YOU!

Author: Shruti Vijay Dhamale Smartcard authentication or client certificate authentication with NetScaler Gateway is a common deployment scenario that we come across-especially with government entities. While this method of authentication enhances security, we do see users being prompted multiple times to choose a certificate or enter pin when trying to establish an ICA connection. This article provides an overview of one of the methods to reduce multiple certificate or pin prompts. Before reviewing the method let's understand what generates the multiple cert prompts. Consider a NetScaler Gateway vServer configured to perform certificate authentication followed by LDAP authentication using n-factor as mentioned below: Authentication Policy add authentication certAction certauth_act -twoFactor ON -userNameField Subject:CN add authentication Policy Certauth_pol -rule true -action certauth_act add authentication ldapAction AD1_SAM -serverIP 172.30.200.20 -ldapBase "dc=citrix,dc=lab" -ldapBindDn citrixservices@citrix.lab -ldapBindDnPassword XXXX -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_11_05_17_13_55 -ldapLoginName sAMAccountName add authentication Policy adv_ldap_sam -rule true -action AD1_SAM LoginSchema add authentication loginSchema ldap1 -authenticationSchema "/nsconfig/loginschema/LoginSchema/PrefilUserFromExpr.xml" -userCredentialIndex 11 -passwordCredentialIndex 12 Policy Label add authentication policylabel ldapauth1 -loginSchema ldap1 bind authentication policylabel ldapauth1 -policyName adv_ldap_sam -priority 100 -gotoPriorityExpression NEXT Authentication vServer add authentication vserver AAA_EPA_GW SSL 0.0.0.0 bind authentication vserver AAA_EPA_GW -portaltheme RfWebUI bind ssl vserver AAA_EPA_GW -certkeyName CitrixDemoCenter-cert bind ssl vserver AAA_EPA_GW -certkeyName Defaultroot -CA -ocspCheck Optional bind authentication vserver AAA_EPA_GW -policy Certauth_pol -priority 100 -nextFactor ldapauth1 -gotoPriorityExpression NEXT set ssl vserver AAA_EPA_GW -clientAuth ENABLED -clientCert Mandatory Authentication Profile add authentication authnProfile EPA_GW -authnVsName AAA_EPA_GW Traffic Policy add vpn trafficAction sso http -SSO ON -userExpression "AAA.USER.ATTRIBUTE(11)" -passwdExpression "AAA.USER.ATTRIBUTE(12)" add vpn trafficPolicy sso true sso Session Policy add vpn sessionAction AC_WB_172.30.200.112 -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -ssoCredential PRIMARY -icaProxy ON -wihome "https://xd1.citrix.lab/Citrix/StoreWeb" -ClientChoices OFF -ntDomain Citrix -clientlessVpnMode OFF -sfGatewayAuthType domain add vpn sessionPolicy PL_WB_172.30.200.112 "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\").NOT" VPN vServer add vpn vserver EPA_Gateway SSL 172.30.200.112 443 -downStateFlush DISABLED -Listenpolicy NONE -authnProfile EPA_GW bind vpn vserver EPA_Gateway -staServer https://xd1.citrix.lab bind vpn vserver EPA_Gateway -portaltheme RfWebUI bind vpn vserver EPA_Gateway -policy PL_WB_172.30.200.112 -priority 100 -gotoPriorityExpression NEXT -type REQUEST bind vpn vserver EPA_Gateway -policy sso -priority 100 -gotoPriorityExpression END -type REQUEST bind ssl vserver EPA_Gateway -certkeyName CitrixDemoCenter-cert bind ssl vserver EPA_Gateway -certkeyName Defaultroot -CA -ocspCheck Optional set ssl vserver EPA_Gateway -clientAuth ENABLED -clientCert mandatory The traffic flow at high-level would be as follows: Client performs an SSL handshake and is presented with a Citrix NetScaler login page. Client provides credentials, and NetScaler connects to an external authentication server for validation. These credentials are presented to the Citrix StoreFront server to perform SSO. Citrix StoreFront after verifying with Citrix DDC enumerates appropriate applications to the user. Client clicks on the application and receives the ICA file. When client launches the ICA file received, a new non-browser session is initiated with NetScaler Gateway vServer. Due to this user receives a new prompt to provide a certificate or enter a pin. After validation is successful, client is connected to the application/desktop. As we can see browser/workspace app caches the information about client certificate/pin and uses it for subsequent SSL handshakes that are done with NetScaler Gateway’s AAA vServer. However, when the session switches from the web to ICA, client gets prompted again to select a certificate/pin to complete the connection. To avoid these multiple prompts, we can use the below-mentioned solution using SAML authentication. Consider a NetScaler Gateway vServer configured with SAML policy configured to redirect the client to another AAA vServer hosted on the same NetScaler instance using SAML IdP that performs certificate authentication followed by LDAP authentication configured as below: Authentication Policy add authentication certAction certauth_act -twoFactor ON -userNameField Subject:CN add authentication Policy Certauth_pol -rule true -action certauth_act add authentication ldapAction AD1_SAM -serverIP 172.30.200.20 -ldapBase "dc=citrix,dc=lab" -ldapBindDn citrixservices@citrix.lab -ldapBindDnPassword XXXX -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_11_05_17_13_55 -ldapLoginName sAMAccountName add authentication Policy adv_ldap_sam -rule true -action AD1_SAM add authentication samlAction saml_sp -samlIdPCertName CitrixDemoCenter-cert -samlSigningCertName CitrixDemoCenter-cert -samlRedirectUrl "https://108-168-156-36.mycitrixdemo.net/saml/login" -samlUserField UserID -samlRejectUnsignedAssertion OFF -samlIssuerName "https://108-168-156-37.mycitrixdemo.net" add authentication Policy saml_sp -rule TRUE -action saml_sp add authentication samlIdPProfile saml_idp -samlSPCertName mylabcert -samlIdPCertName mylabcert -assertionConsumerServiceURL "https://108-168-156-37.mycitrixdemo.net/cgi/samlauth" -samlIssuerName "https://108-168-156-36.mycitrixdemo.net" -signatureAlg RSA-SHA1 -digestMethod SHA1 -Attribute1 Userid -Attribute1Expr "AAA.USER.ATTRIBUTE(11)" -Attribute2 Password -Attribute2Expr "AAA.USER.ATTRIBUTE(12).B64ENCODE" -serviceProviderID "https://108-168-156-37.mycitrixdemo.net" add authentication samlIdPPolicy saml_idp -rule TRUE -action saml_idp LoginSchema add authentication loginSchema ldap1 -authenticationSchema "/nsconfig/loginschema/LoginSchema/PrefilUserFromExpr.xml" -userCredentialIndex 11 -passwordCredentialIndex 12 Policy Label add authentication policylabel ldapauth1 -loginSchema ldap1 bind authentication policylabel ldapauth1 -policyName adv_ldap_sam -priority 100 -gotoPriorityExpression NEXT Authentication vServer (SAML IdP) add authentication vserver SAML_IDP SSL 172.30.200.111 443 bind authentication vserver AAA_EPA_GW -portaltheme RfWebUI bind ssl vserver SAML_IDP -certkeyName CitrixDemoCenter-cert bind ssl vserver SAML_IDP -certkeyName Defaultroot -CA -ocspCheck Optional bind authentication vserver SAML_IDP -policy saml_idp -priority 100 -gotoPriorityExpression NEXT bind authentication vserver SAML_IDP -policy Certauth_pol -priority 100 -nextFactor ldapauth1 -gotoPriorityExpression NEXT set ssl vserver SAML_IDP -clientAuth ENABLED -clientCert Mandatory Authentication vServer (SAML SP) add authentication vserver AAA_EPA_GW SSL 0.0.0.0 bind authentication vserver AAA_EPA_GW -portaltheme RfWebUI bind ssl vserver AAA_EPA_GW -certkeyName CitrixDemoCenter-cert bind authentication vserver AAA_EPA_GW -policy saml_sp -priority 100 -gotoPriorityExpression NEXT Authentication Profile add authentication authnProfile EPA_GW -authnVsName AAA_EPA_GW Traffic Policy add vpn trafficAction sso http -SSO ON -userExpression "AAA.USER.ATTRIBUTE(1)" -passwdExpression "AAA.USER.ATTRIBUTE(2)" add vpn trafficPolicy sso true sso Session Policy add vpn sessionAction AC_WB_172.30.200.112 -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -ssoCredential PRIMARY -icaProxy ON -wihome "https://xd1.citrix.lab/Citrix/StoreWeb" -ClientChoices OFF -ntDomain Citrix -clientlessVpnMode OFF -sfGatewayAuthType domain add vpn sessionPolicy PL_WB_172.30.200.112 "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\").NOT" VPN vServer add vpn vserver EPA_Gateway SSL 172.30.200.112 443 -downStateFlush DISABLED -Listenpolicy NONE -authnProfile EPA_GW bind vpn vserver EPA_Gateway -staServer https://xd1.citrix.lab bind vpn vserver EPA_Gateway -portaltheme RfWebUIbind vpn vserver EPA_Gateway -policy PL_WB_172.30.200.112 -priority 100 -gotoPriorityExpression NEXT -type REQUEST bind vpn vserver EPA_Gateway -policy sso -priority 100 -gotoPriorityExpression END -type REQUEST bind ssl vserver EPA_Gateway -certkeyName CitrixDemoCenter-cert bind ssl vserver EPA_Gateway -certkeyName Defaultroot -CA -ocspCheck Optional In this method, the certificate or smart card check is offloaded to AAA vServer acting as an Idp server. So once client is authenticated, their credentials are returned using the SAML attribute to the AAA vServer bound to NetScaler Gateway vServer, which can be then used for SSO with CVAD infrastructure. Notice the difference in authentication policy bindings, client cert setting in SSL parameters for AAA vServer, and SSO credential index used in traffic profile in both scenarios. The traffic flow at high-level would be as follows: The Client performs an SSL handshake with NetScaler Gateway vServer and is redirected to a SAML IdP vServer configured on the same NetScaler. Client performs SSL handshake with AAA vServer that acts as IdP vServer and presents Client certificate. Upon certificate validation, client is presented with the Citrix NetScaler login page. Client provides credentials, and NetScaler connects to an external authentication server to validate the user. Once authenticated, client connects back to NetScaler Gateway vServer, with credentials returned as a part of SAML attributes. These credentials are presented to the Citrix StoreFront server to perform SSO. Citrix StoreFront after verifying with Citrix DDC enumerates appropriate applications to the user. Client clicks on the application and receives the ICA file. NetScaler requests the IP address from the STA server for the resource requested, post that the ICA connection is established. To obscure the credentials further, you can also base64 encode the credentials when configuring the SAML attribute. For an alternative method to reduce multiple prompts, a separate NetScaler Gateway vServer for call-back can also be used as described in this blog. The trace files from the demo environment are available here.

Author: Shruti Vijay Dhamale A lot of organization’s implement restrictions on the internet access-based security policies configured to check the destination IP addresses or domain names. As the organizations are moving to cloud services like Microsoft 365, These traditional access lists are failing as the services are hosted in public cloud and utilize shared domain names such as outlook.office.com and login.microsoftonline.com. So, users can use their personal resources using same domain names. To restrict the user access, blocking these addresses would keep users from accessing Outlook on the web entirely, instead of merely restricting them to approved identities and resources. To address this issue, Microsoft introduced an HTTP custom headers based feature called tenant restrictions to help administrators control access to Microsoft tenant. Restrict-Access-To-Tenants, use a value of <permitted tenant list>, which is a comma-separated list of tenants. Any domain that is registered with a tenant can be used to identify the tenant in this list, as well as the directory ID itself.Restrict-Access-Context, use a value of a single directory ID, declaring which tenant is setting the tenant restrictions.NetScaler SSL Forward Proxy allows administrators to implement SSL inspection at granular level to implement security policies efficiently. NetScaler’s SSL interception feature combined with Rewrite feature allows administrators to implement Microsoft tenant restriction in just a few steps described as below. Let’s get started. So, assuming you have implemented SSL forward proxy setup in your environment. You have confirmed that the SSL interception, connectivity to internet works as expected. Ensure that the users can resolve and connect to various Office365 URLs and IP addresses defined by Microsoft. We then begin with the configuration specific for tenant restrictions- Create a pattern set (patset) listing Azure AD urls used for authentication. add policy patset PATSET_MS_Tenant_Restriction bind policy patset PATSET_MS_Tenant_Restriction login.windows.net -index 1 bind policy patset PATSET_MS_Tenant_Restriction login.microsoft.com -index 2 bind policy patset PATSET_MS_Tenant_Restriction login.microsoftonline.com -index 3 Configure SSL Policy to allow interception for this patset. add ssl policy SSLPOLICY_MS_Tenant_Restrction -rule "CLIENT.SSL.CLIENT_HELLO.SNI.EQUALS_ANY(\"PATSET_MS_Tenant_Restriction\")" -action INTERCEPT Configure two Rewrite Policies to insert HTTP headers Restrict-Access-Tenants and Restrict- Access-Context add rewrite action RWACTION_MS_Tenant_Restriction_1 insert_http_header Restrict-Access-To-Tenants "\"domain.com,domain.onmicrosoft.com,xxx-xxx-xxx\"" add rewrite action RWACTION_MS_Tenant_Restriction_2 insert_http_header Restrict-Access-Context "\"456ff232-35l2-5h23-b3b3-3236w0826f3d\"" add rewrite policy RWPOLICY_MS_Tenant_Restrction_1 "HTTP.REQ.HOSTNAME.EQUALS_ANY(\"PATSET_MS_Tenant_Restriction\")" RWACTION_MS_Tenant_Restriction_1 add rewrite policy RWPOLICY_MS_Tenant_Restrction_2 "HTTP.REQ.HOSTNAME.EQUALS_ANY(\"PATSET_MS_Tenant_Restriction\")" RWACTION_MS_Tenant_Restriction_2 Bind the policies to SSL Proxy vServer. Ensure the policies do not conflict with the existing policies. bind ssl vserver PROXYVSRV_Explicit_Citrixdemo -policyName SSLPOLICY_MS_Tenant_Restrction_ssli -priority 100 -type INTERCEPT_REQ bind cs vserver PROXYVSRV_Explicit_Citrixdemo -policyName RWPOLICY_MS_Tenant_Restrction_1 -priority 100 -gotoPriorityExpression NEXT -type REQUEST bind cs vserver PROXYVSRV_Explicit_Citrixdemo -policyName RWPOLICY_MS_Tenant_Restrction_2 -priority 110 -gotoPriorityExpression END -type REQUEST The Microsoft Tenant Restriction must be active now. If the configuration is in place correctly now, in the packet trace you would see that headers are inserted when the request is sent from NetScaler SNIP to Microsoft servers. Observe the below request sent by the client to Proxy vServer, which does not contain any information about the tenants it needs to access When this same request is sent from SNIP on NetScaler to the Microsoft servers, we see the rewrite policies taking effect and headers being inserted as below.

Authors: Vaibhav Khare, Satyam Mehrotra Security is always a top priority for any business. Central to this for internet-facing applications is ensuring that the data is not intercepted, viewed or changed by unauthorized users. To protect this sensitive data from compromise, cryptographically secure encryption is critical for all applications. Cryptographic processes like SSL/TLS come at a price. The CPU load on servers to process encryption and decryption is severe and can impact the performance of the backend server and hence the application itself. As a pioneer in the Application Delivery Controller (ADC) market, NetScaler was the first ADC to introduce integrated SSL offload in 2002. This relieved much of the hard graft of SSL processing for businesses and lowered the TCO. Further benefits of SSL offloading extended beyond direct cost. Access to the higher layers meant encrypted traffic could be inspected and secured, as well as directed more intelligently. Moreover, centralizing the SSL made for much less complex certificate management. SSL ChallengesSSL is not without challenges. Over time vulnerabilities in the SSL protocol have been discovered and exploited (e.g. POODLE), and advances in computing power have rendered low strength ciphers insecure and vulnerable to attack. Similarly, older SSL versions lack support for modern security features like Perfect Forward Secrecy (PFS), which provides increased protection against eavesdropping and decryption of past communication even if the private key is compromised. While it is important to configure all the SSL elements to suit a particular environment for maximum security, this can be a manual and time-consuming process. More than this, it is error-prone, which can lead to security gaps and exposure of sensitive data. Enhanced SSL profiles to ensure consistent configurationTo solve this problem, NetScaler introduced SSL profiles. SSL profiles are a single point of configuration that can bind SSL configuration specifications to an entity. The ability to group parameters like SSL protocol versions, client/server authentication parameters, Diffie-Hellman parameters as well as cryptographic settings for ciphers and ECC curves and more, make SSL configuration simpler. SSL profiles improve the time to protection and reduce configuration workload. More than this, however, it makes it easy to ensure consistent configuration and compliance with corporate security policies and industry regulation while dramatically minimizing SSL errors, which reduces the risk of security gaps. Enhanced SSL Profiles can be enabled from GUI (Figure 1) or via the following command: Set ssl parameter -defaultProfile ENABLED Figure 1: Enable Enhanced SSL profiles under Traffic Management > SSL > Advanced SSL Settings (NOTE: Once enabled, the only way to disable is to clear the NetScaler config) Types of SSL profilesThere are two types of SSL profiles. Frontend profiles are bound to internet/client-facing entities, while backend profiles define the settings for entities that interact with the application server resources. While similar in content, some parameters are only applicable to certain environments. For example, frontend profiles have settings for client authentication and backend profiles have settings for server authentication. Similarly, the different profiles have different default cipher groups included – although it is possible to change these to be the same. Overall, there are more configurable elements in a frontend profile than in the backend profile (see Figure 2 and Figure 3 for a comparison) Figure 2: Parameter settings for default frontend SSL profile Figure 3: Parameter setting for default backend SSL profile NetScaler includes a number of default profiles, which contain settings that are suitable for most scenarios. While these default settings are configured with the most secure SSL protocols and cryptographic settings and can be used as they are, all are fully customizable and can be tailored to suit customer-specific environments and security policies. It is, however, not possible to delete or rename the default profiles, but NetScaler provides users with the flexibility to create their own SSL profiles, give them meaningful names that fit with their corporate policies and apply them to the SSL end points as required (Figure 4). Figure 4: User defined SSL Profiles can be bound to different virtual servers as required Advantages of SSL ProfilesThe biggest advantage of using SSL profiles is that they can be bound to multiple SSL endpoint entities on demand. Configuring SSL parameters for every individual entity is a tedious, manual task, that is prone to error. SSL profiles are simple to use (Figure 5) and remove many of the repetitive steps. Attaching a profile to an SSL end-point can be done from the NetScaler GUI or using the CLI command: set ssl vserver <name> -sslprofile <name of ssl profile> Figure 5: Binding an SSL profile to an SSL End point is quick, easy and error-free from the GUI Traffic Management > Load Balancing > Virtual Servers Figure 6 shows how much easier it is to configure SSL settings on end-points with SSL profiles. Instead of 4 individual config changes, the admin only needs to configure the profile once and then bind it to each entity to which those settings apply. Once bound, any update to the profile – changing to stronger ciphers, for example – is propagated to each entity automatically. Figure 6: Configuring with profiles is much quicker, simpler and less prone to error Best Practices for SSL NetScaler strongly recommends the use of Enhanced SSL profiles as a best practice for all SSL configuration. These profiles contain the full suite of SSL parameters required to make your applications secure and protect your data. They are simpler to use and far less likely to leave security gaps in your infrastructure caused by errors. Most new SSL functionality on NetScaler will only be accessible via enhanced SSL profiles. For example, the only way to implement TLS v1.3 is to enable enhanced SSL Profiles. To make it easier for existing customers with legacy configs, NetScaler has created a tool to aid migration to enhanced SSL profiles. This tool will scan the config file and automatically generate the correct commands to run to update the configuration to use enhanced SSL profiles. Customers can take advantage of the tighter security features in minutes. While there should never be shortcuts with security, SSL profiles are an excellent way to both reduce potentially damaging errors and automate configuration. We envision a day when all configuration is this simple and secure. For more information on the SSL profile infrastructure, please visit the eDocs.