How to Redirect Requests on Port 80 to 443 Using the Redirect URL Feature on NetScaler

  • Click Add to create a Load Balancing virtual server. The VIP should be the same as the Port 443 Virtual Server. The Port number should be 80.

    User-added image

    3. Click Continue.

    User-added image

    4. Click Protection Tab.

    User-added image

    5. Add the redirect URL as desired, then click OK and Done.

    User-added image

    6. You will notice that the LB is marked down and this is expected. This is what triggers the protection function and subsequent redirect.

    User-added image

    7. In the following screenshot you will see the request landing on the LB VIP created in the preceding step and then the request being redirected to the HTTPS site as configured.

    User-added image

  • Related:

    SSL Handshake Fails When Server Name Indication (SNI) is Enabled on NetScaler

    SSL handshake fails when Server Name Indication feature is enabled on NetScaler.

    User-added image

    Server Name Indication aka SNI is an extension of the TLS protocol. 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 backend server is www.mail.example.com, the SNI-enabled back-end service must be configured with the server name as https://www.mail.example.com, and this host name must match the server name in the client hello.

    Related:

    7023362: Failed to create certificate request – countryName

    This document (7023362) is provided subject to the disclaimer at the end of this document.

    Environment

    Privileged Account Manager

    Situation

    Unable to create a Certificate Signing Request (CSR) from the Hosts Console
    The following browser dialog error when requesting a certificate for the framework manager console:
    Failed to create certificate request
    The following is found in the unifid.log:
    Error, Error adding attribute countryName to request

    Info, SSL Error: error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long

    Info, admin certRequest client:localhost user:admin@<hostname>(137.65.60.249) rc:0 status:500(Failed to create certificate request) (66ms)[42078208:42078208]<90112><327680>

    Resolution

    The Country field of a Certificate Signing Request should be a 2-character ISO format country code.
    More details can be found from documentation provided by the Certificate Authority (CA).
    The following is a list of SSL Certificate Country Codes provided by Digicert as an example:

    Cause

    Invalid details provided in conflict with the certificate authority documentation.

    Disclaimer

    This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

    Related:

    • No Related Posts

    Receiver for HTML5 – Unable to Launch Apps Using HTTPS URL

    Recommended Solution(s) for All Browsers

    • Connect via Netscaler Gateway even for internal connections. This would ensure connections work fine regardless of XA or XD versions.

      User-added image

      Deploying SSL/TLS for each VDA for direct connections. Receiver for HTML5 supports secure direct SSL/TLS connections with XenApp/XenDesktop 7.6

      User-added image

    Read the following articles from the Citrix Blog for more information:

    Mozilla Firefox

    There is a possible workaround for Mozilla Firefox browser.

    Note: This workaround has security implications; consult the security specialist of your organization to consider the following configuration.

    1. Enforce secure communications between Citrix Receiver for HTML5 and applications or desktops (for example, using IPSec).

    2. Use Mozilla Firefox only for Citrix Receiver for HTML5 (not for general website use).

    3. Enforce a secure configuration for Firefox.

    4. Enable the Firefox network.websocket.allowInsecureFromHTTPS option.

    If the preceding configuration is consistent with the security policy of your organization, an administrator can enable launching applications or desktop using the following steps:

    1. Open a new tab in the Firefox browser.

    2. Type about:config in the address bar.

    3. Double-click network.websocket.allowInsecureFromHTTPS and set the value to true.

    Note: This Firefox option might not be supported in Citrix Receiver for HTML5 future versions.

    WARNING! This option on Firefox affects the operation of entire Firefox, not just Citrix Receiver for HTML5.

    Important Note

    As of version 9, Safari browser allows insecure web socket connections. Internet Explorer never allowed non SSL/TLS web socket connections from HTTPS websites. Chrome used to allow it behind a flag, but after the Chrome 44 update, this is no longer supported. Firefox allows it behind a flag (as explained earlier in this article), but it is not recommended. Going forward, only secure (SSL/TLS) web socket connections can be made from Receiver for HTML5.

    How Do I Articles

    Related:

    AES – GCM Ciphers supportability at ADC

    On ADC, if AES-GCM Ciphers are bound as Priority at the SSL Virtual Server, the SSL handshake fails with the Back End server if the ADC Firmware version 11.0 or lower.

    For the Front End SSL connection to the Virtual Server, AES-GCM based Ciphers are supported from 10.5 53.x Firmware version.

    For more details, please check the document below:

    https://docs.citrix.com/en-us/netscaler/12/ssl/cipher_protocl_support_matrix.html

    Related:

    Case Study – Web Browser Displays “401 – Unauthorized: Access is denied due to invalid credentials”

    Problem Definition

    A customer was attempting to configure ICA Proxy mode on Citrix Access Gateway Enterprise Edition with XenApp 5.0 and Web Interface. The customer reported that when configuring the same, the 401 – Unauthorized Access is denied due to invalid credentials error message is displayed on the Web browser after a successful authentication to the Citrix Access Gateway Enterprise Edition Login page, as shown in the following screenshot:

    User-added image

    Environment

    The customer had installed the following hardware and software components on the network:

    • Windows Server 2008
    • Internet Information Server 7
    • NetScaler appliance
    • Web Interface 5.0
    • XenApp 5.0

    Troubleshooting Methodology

    To troubleshoot this issue, the Technical Support Engineers investigated the Windows event logs of the XenApp Server and observed an error message in the Citrix Web Interface event log, as shown in the following screenshot:

    User-added image

    This prompted the engineers to shift the focus of the investigation towards the XenApp Server. The engineers recorded network packet traces on the XenApp server during a login attempt. Each time, the engineers killed the Access Gateway Enterprise Edition session to ensure that a new session starts. The Web Interface makes the outbound https request to the Access Gateway Enterprise appliance to retrieve the SmartAccess settings, such as VServer and Session Policy Name.

    When analyzing the packet traces, the engineers observed that when the XenApp Server communicates to the URL in the preceding screenshot, /CitrixAuthService/AuthService.asmx, the XenApp Server sends a FIN-ACK packet during the Secure Socket Layer (SSL) handshake negotiation, as shown in the following screenshot:

    User-added image

    When attempting to open the /Citrix/XenApp1/auth/agesso.aspx URL, the Web Interface sends the 401 response code because the XenApp server could not complete the SSL handshake.

    After further investigating the event logs, the engineers noticed that there was an issue with the SSL certificates.

    Related:

    NetScaler Gateway, StoreFront and XenDesktop Integration Communication Workflow

    Topics

    1. Introduction

    2. Detailed Workflow

    1. Introduction

    In this article, we will talk about NetScaler Gateway+StoreFront+XenDesktop workflow. I will separate the workflow into 5 steps.

    1. SSL Connection
    2. Authentication
    3. Get the App/Desktop list.
    4. Click one app and get the ica file.
    5. Launch app/desktop.

    Back to top

    2. Detailed Workflow

    In this section, we will analyze the detailed workflow of the previous 5 steps. Here are my environment machines.

    Client: 10.107.197.250

    NetScaler: VIP: 10.107.197.243

    NSIP: 10.107.197.241

    Subnet IP: 10.107.197.242

    StoreFront: 10.107.197.236

    DDC/STA: 10.107.197.235

    VDA: 10.107.197.238

    Back to top

    2.1. SSL Connection

    This is the first step when user type the NetScaler Gateway vServer’s address into browser. We need to focus on the SSL handshake between client and server if any issue happens.

    Note: NSG means “NetScaler Gateway” in this article.

    User-added image

    a. Client_Hello

    Client_Hello is the first packet of the TLS handshake, we can check the following items in it:

    i. SNI

    ii. Cipher Suits

    iii. Protocol

    User-added image

    b. Server Hello

    Server hello is the response of client hello, used to negotiate the protocol version and cipher suite from client hello, these items are very important for subsequent encryption.

    User-added image

    c. Certificate

    Server sends its certificates to client, so that client can verify if the certificates are trusted or not.

    User-added image

    d. Key Exchange & Change Cipher Spec

    Most of SSL/TLS issues are happened in above 3 steps. The “Key Exchange” step is used to negotiate the master key and session key for the data encryption. And use “Change cipher Spec” step to enter the data encryption channel.

    User-added image

    e. HTTPs data (encrypted HTTP requests and responses)

    After handshake, client and server send HTTP requests and responses encrypted by the key negotiated in the SSL/TLS handshake.

    User-added image

    How to decrypt these HTTP data at client side? Check this article: https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/

    Back to top

    2.2. Authentication

    Commonly, customer uses LDAP domain authentication. In this article, I will use dual factor authentication as an example (LDAP+Radius).

    LDAP: AD

    Radius: freeradius

    User-added image

    a. Client type the user credential and send to NSG vServer.

    User-added image

    User-added image

    Note: Here I use the NSG’s private key to decrypt the HTTPs data.

    b. NSG communicate with LDAP server and Radius server to verify the user’s credential.

    b.1. bindRequest is sent to LDAP server to authorize NSG itself and LDAP server respond success. Here the user “administrator@donnie.com” is configured in NetScaler’s LDAP policy.

    User-added image

    b.2. searchRequest is sent to LDAP server to check the login user’s existence.

    User-added image

    b.3. LDAP server responds the searchRequest by searchResEntry, searchResEntry contains some LDAP info such as the login user’s group information.

    User-added image

    b.4. NSG sends a new bindRequest to LDAP server to verify the login user’s password.

    User-added image

    b.5. NSG verifies the token information with Radius server and server responses Access-Accept.

    User-added image

    c. NSG responses client with a normal 302 response and another 200 response to redirect the URL to StoreFront.

    User-added image

    d. User click “Login” again in the StoreFront page. A new login request sent to SF. Here user doesn’t need to type his username/password again.

    User-added image

    e. NSG communicates with SF to pass SF’s authentication.

    e.1. NSG sends the request to SF and SF responds 401 to ask NSG to perform authentication.

    User-added image

    e.2. NSG sends the user’s info to SF by using CitrixAGBasic authentication method.

    User-added image

    Note: they are base64 encoded, wireshark can decode them automatically.

    e.3. SF verifies the user’s username and password by contacting AD server with protocol Kerberos.

    User-added image

    e.4. SF returns 200 OK to NSG.

    User-added image

    f. NSG returns the same 200 OK to client.

    Back to top

    2.3. Get the App/Desktop List.

    User-added image

    a. Client sends the list request to NSG.

    User-added image
    b. NSG forwards this request to SF.

    User-added image

    c. SF sends callback message to NSG to get the vServer/Policy information. This is very useful when enable SmartAccess. If SmartAccess is not enabled. The callback address doesn’t need to be configured in SF.

    User-added image

    d. SF checks with DDC for the available Apps and Desktops related to this client. Note that the session policy information is here, it’s got from the previous callback request. So that DDC can use it’s Access Policy to determine the matched apps and desktops based on this.

    User-added image

    e. DDC responses the available Apps list to SF.

    User-added image

    f. SF converts the response into json format and sends it to NSG. Each object is for each app/desktop.

    User-added image

    g. NSG sends this response to client. Note that the ica file URL is also in this response.

    User-added image

    Back to top

    2.4. Get the ica file.

    User-added image

    a. Client sends the request to NSG to get the ica file.

    User-added image

    b. NSG forwards this request to SF.

    c. SF gets the VDA information from DDC. Such as IP, port info.

    User-added image

    d. DDC responses SF.

    User-added image

    e. SF contacts STA server to get the STA ticket information.

    User-added image

    f. SF generates ica file and sends it back to NSG.

    User-added image

    g. NSG forwards the response to client. The content is the same as step f.

    User-added image

    5. Client launch app/desktop

    User-added image

    a. Client sends ICA data to the same NetScaler vServer. This is not http protocol. Note that only Receiver 4.6 or above supports SNI.

    User-added image

    b. NSG verifies the STA ticket with STA server.

    User-added image

    c. STA server responses valid result and the VDA server’s info(IP+port).

    User-added image

    d. NSG connects VDA’s 1494 port for the virtual desktop data.

    User-added image

    e. NSG acts as a “proxy” between client and VDA.

    Back to top

    Related:

    Untrusted SSL server certificate Error.

    I need a solution

    Hi Team,

    We are getting “untrusted SSL server certificate(ssl_server_cert_untrusted_issuer)”

    We have already added teh CA certificate in the browser list and also the error seems like host name mismatch in the domain and the certificate which issued.

    But customer confirmed that the url domain added in the certificate (SAN field) as well.

    I am not sure that the proxy replaced with the legitimate one and show this error.

    I have refered below KB which suggested to disable cert validation. please advice on this.

    https://support.symantec.com/en_US/article.TECH246…

    Thanks,

    Ram

    0

    Related:

    • No Related Posts

    StoreFront Loopback Feature

    Citrix recommends that you modify the hosts file on your StoreFront servers to ensure that Receiver for Web always talks to the local StoreFront server instead of the load balancer. In StoreFront 3.0, we leverage a new feature in the .NET Framework 4.5 to implement loopback communication between Receiver for Web and the rest of StoreFront Services.

    This is configurable using PowerShell cmdletSet-DSLoopback, which syntax is

    Set-DSLoopback [-SiteId] <Int64> [-VirtualPath] <String> ` [-Loopback] <String>

    [[-LoopbackPortUsingHttp] <Int32>]

    User-added image


    The valid values for Loopback are:

    • On – This is the default value for new Receiver for Web sites. Receiver for Web uses the schema (HTTPS or HTTP) and port number from the base URL but replace the host part with the loopback IP address to communicate with StoreFront Services. This works for a single server deployment and a deployments with a non SSL-terminating load balancer.

    • OnUsingHttp – Receiver for Web uses HTTP and the loopback IP address to communicate with StoreFront Services. If you are using an SSL-terminating load balancer, you should select this value. You have to also specify the HTTP port if it is not the default port 80.

    • Off – This turns off loopback and Receiver for Web uses the StoreFront base URL to communicate with StoreFront Services. If you perform an in-place upgrade this is the default value to avoid disruption to your existing deployment. For example, if you are using an SSL-terminating load balancer, your IIS is configured to use port 81 for HTTP and the path of your Receiver for Web site is /Citrix/StoreWeb, you can run the following command to configure the Receiver for Web site:

      Set-DSLoopback -SiteId 1 -VirtualPath /Citrix/StoreWeb ` -Loopback OnUsingHttp -LoopbackPortUsingHttp 81


    Switch off loopback if you want to use any web proxy tool like Fiddler to capture the network traffics between Receiver for Web and StoreFront Services. Delegating Authentication to the Backend Providers StoreFront 2.x always communicates with the Active Directory to authenticate users. This requires that the domain hosting StoreFront servers has at least one-way external trust to the domain hosting the backend XenApp/XenDesktop farms/sites. This may not be possible in some deployments. StoreFront 3.0 adds the capability to delegate authentication to the XenApp/XenDesktop farms/sites. This can be enabled by running the following PowerShell commands. Replace the store and authentication virtual paths appropriately.

    ## set some variables relevant to your deployment $SiteId = 1 $StoreVirtualPath = “/Citrix/Store” $AuthenticationVirtualPath = “/Citrix/Authentication” # change auth service to use XML Service auth instead of domain auth Set-DSXmlServiceAuthentication -SiteId $SiteId -VirtualPath $AuthenticationVirtualPath $fs = @(Get-DSFarmSets -IISSiteId $SiteId -VirtualPath $StoreVirtualPath) | where { $_.Name -eq “Default” } Update-DSFarmSet -IISSiteId $SiteId -VirtualPath $AuthenticationVirtualPath -Farmset $fs

    Note: From StoreFront 3.5 and newer, you can enable loopback in the StoreFront Console.

    Related:

    How to Replace the Default Certificate of a NetScaler Appliance with a Trusted CA Certificate that Matches the Hostname of NetScaler

    This article describes how to replace the default certificate (ns-server-certificate) of a NetScaler appliance with a trusted Certificate Authority (CA) certificate that matches the hostname of the appliance.

    Background

    On a new NetScaler appliance shipped from Citrix, the default certificate-key pair ns-server-certificate is added to the appliance when it initializes. However, when you upgrade the software of the appliance, no default certificate-key pair is created. You must add the default certificate-key pair by running the following command from the command prompt of the appliance:

    add ssl certKey ns-server-certificate -cert ns-server.cert -key ns-server.key

    After adding the certificate-key pair, it is automatically bound to the following internal services:

    • nskrpcs-127.0.0.1-3009

    • nshttps-127.0.0.1-443

    • nsrpcs-127.0.0.1-3008

    The internal services can be viewed from the Configuration Utility. Navigate to Traffic Management > Load Balancing > Services and click Internal Services tab as shown in the following screen shot:

    User-added image

    The procedure discussed in this article assumes that you have prior knowledge of completing the following tasks:

    • Creating a Private Key

    • Creating a Certificate Signing Request

    • Obtaining a Certificate from a Certificate Authority

    Refer to CTX109260 – How to Generate and Install a Public SSL Certificate on a NetScaler Appliance for help on these tasks.

    Related:

    • No Related Posts