The request for resources/list can be very time consuming and can take upto 30 seconds in worst cases (depending on the performance of the network, StoreFront server or other components). This can cause timeout on the Receiver UI. But the response has been received successfully on the Receiver side. Refer to the Disclaimer at the end.

• Citrix Receiver Cannot Connect To Server 40 Stations
• Citrix Receiver For Mac Cannot Connect To Server 40 Sta
• Citrix Receiver Cannot Connect To Server 40 State

• Contact your help desk with the following information: Cannot connect to the Citrix XenApp Server. The Citrix SSL server you have selected is not accepting connections'. Download Firefox 53.067 64-bit. It seems that the 32-bit version of Firefox 52.0.2 is not working and causing these errors. Citrix XenDesktop 7.12 and Mozilla Firefox.
• As mentioned, for server machines Citrix now includes a multi-user ICA stack, which extends the Windows Remote Desktop Services with the HDX protocol. This is the same ICA protocol stack developed for Citrix XenApp 6.5, just with a different management interface to make it compatible with XenDesktop 7.x controllers.
• Cannot connect to the citrix metaframe server. Resolution: The client device does not have an installed or registered DLL for verifying the Certificate Revocation List (CRL). The Win9x/WinNT 4 operating systems do not support CRL checking.

Error Message: Troubleshooting SSL Error 4 with Secure Gateway
Resolution: Refer to CTX105390 - Troubleshooting SSL Error 4 with Secure Gateway
Error Message: SSL security context is invalid or expired (SSL 15).
Resolution: Upgrade the Win32 ICA client to version 6.30.1050 or later.
Error Message: Cannot connect to the Citrix MetaFrame server. There is no route from the Citrix SSL Relay to the specified subnet address (SSL error 37).
Resolution: Refer to CTX103203 - Error: Cannot connect to the Citrix MetaFrame server. There is no route from the Citrix SSL Relay to the specified subnet address (SSL error 37).
Error Message: SSL Error 37: The proxy could not connect to ;10; (STA server);(sid) port 1494”
Cause: This problems seems to occur only when the XenApp server and ICA Client are using different DNS servers
Resolution: Enabling XML Service DNS address resolution allows a XenApp server to return the Fully Qualified Domain Name (FQDN) to ICA Clients using the Citrix XML Service
Error Message: The Citrix SSL Relay sent a close alert (SSL Error 43)” or SSL Error 4.
Resolution: Refer to the following Knowledge Center articles:
CTX101685 - �The Citrix SSL Relay sent a close alert (SSL Error 43)� or SSL Error 4
CTX116743 - Error: Cannot connect to the Citrix Presentation Server. SSL Error 43
Error Message: The Remote SSL peer sent a bad certificate alert. (SSL Error 49).
Resolution: Upgrade the Macintosh ICA client to version 6. 20.142.
Error Message: The remote SSL peer sent an unrecognized alert (SSL Error 55)....Error : 132
Reason: The SSL Error 55 is caused by an invalid certificate or a missing root certificate.
Resolution: Install an appropriate certificate.
Error Message: Security alert: The name on the security certificate does not match the name of the server (SSL error 59).
Reason:The ICA Client is attempting to connect to the server using its NetBIOS name, IP address, or a fully-qualified domain name (FQDN) that does not match the subject of the server's certificate. To connect successfully, the ICA Client must connect using the DNS name of the server exactly as it appears on the server certificate.
Resolution: In the NFuse scenarios, you must set AddressResolutionType=dns or dns-port in nfuse.conf and enable DNS name resolution on the farm properties panel in the Citrix Management Console. Refer to the following documents for more information about DNS name resolution:
Page 65 of the Administrator's Guide for MetaFrame XP with Feature Release 1.
CTX113264 - SSL Error 59: The Security Certificate and the SSL Connection Does Not Match When Reconnecting Applications Through Advanced Access Control
CTX113568 - Error: SSL error 59 ... When Connecting to Web Interface and Secure Gateway Through Presentation Server Client 10.0
CTX114315 - Case Study: When Accessing a Secure Gateway Site Using the MAC Intel Client, Users Receive an SSL 59 Error Message
Error Message: Any of the following error messages:
The server certificate received is not trusted (SSL error 61).
Cannot connect to the Citrix (XenApp or Presentation) Server.
SSL Error 61: You have not chosen to trust “Common”, the issuer of the server’s security certificate.
The following are the probable reasons for these error messages:
The required Certificate Authority (CA) Root certificate is not installed on the client device.
If the server certificate was issued by an intermediate certification authority, the Win32 ICA Client version 6.20.985 does not connect using SSL. This is a client-side issue that affects the 32-bit ICA Client Version 6.20.985 connecting through the Citrix SSL Relay Service or Citrix Secure Gateway.
The validity of the server certificate presented also relies on the client date and time. The SSL error 61 has is also displayed if the client time is outside the validity period (date time stamp) of the server certificate.
Administrator might have configure Citrix Secure Gateway to have the client log in to the Web Interface site, which then redirects the client to the Citrix Secure Gateway appliance after the application has started. The Secure Gateway appliance proxies the connection. If DNS is not correct, the client machine might be directed or resolved to a site that it actually does not trust. When directly accessing the Citrix Secure Gateway Server from the client machine, the client displays the following security alert:

If you display the certificate, it indicates that it was not from the Citrix Secure gateway site.
Resolutions: The following are the probable resolutions for these error messages:

Refer to CTX101990 - The server certificate received is not trusted (SSL Error 61)
If you are using a well-known public certification authority, such as VeriSign, Baltimore, Thawte, or RSA, then the required root certificate already exists on the client devices running a recent copy of Windows. However, if you either are using your own certificate server to generate server certificates or a trial certificate from a CA, you need to install the CA Root certificate on all client devices for them to connect. For more information about CA Root certificates and the necessity of the same, refer to the white paper CTX16830 - Using the Citrix SSL Relay.
If the issue related to the client-side affecting the 32-bit ICA Client Version 6.20.985 connecting through the Citrix SSL Relay Service or Citrix Secure Gateway is resolved in versions 6.20.986 and later of the Win32 ICA Client. You can download the latest version of the Win32 ICA client from the Citrix Web site.
If the issue related to the client date and time being invalid, then adjust the client time to reflect the current and date.
For the DNS resolution issue, ensure that the DNS is properly configured between the client computer and the FQDN of the Citrix Secure Gateway Server.

Error Message: The connection was rejected. The SSL certificate is no longer valid. Please contact your Citrix Administrator (SSL error 70).
Reason: The server certificate installed on the MetaFrame server is not yet valid or has expired. A common problem observed when using Microsoft Certificate Services to generate digital certificates in-house is that the period of validity might not begin until the day after the certificate is generated.
Resolution: The SSL server certificates typically have a fixed set of valid dates. The system clock of the client devices as well as the server must be set to a time that falls within that range for an SSL connection to succeed. To determine the validity date of your server certificate, double-click the certificate file and notice the Valid from and Valid to fields.
Error Message: On the Macintosh computer, one or more of the root certificates in the keystore are not valid (SSL error 73).
Reason: The Macintosh root certificate might to be in a CER format.
Resolution: The Macintosh certificates need to be in a DER format with the .crt extension. If the root certificate is copied properly to the keystore/cacerts folder and the user still gets this error when trying to connect, then refer to CTX104638 - Error: One or more of the certificates in the keystore directory are not trusted (SSL Error 73) to resolve the issue.
Error Message: SSL Error 82: The Security certificate (TheNameOfYourCertificateAuthority) is not suitable for use in SSL connections. Reason: Unsuitable Netscape Usage Extension field.
Resolution: Refer to CTX113002 - SSL Error 82: The Security certificate (TheNameOfYourCertificateAuthority) is not suitable for use in SSL connections. Reason: Unsuitable Netscape Usage Extension field.
Error Message: Cannot connect to the Citrix (XenApp or Presentation) Server. There in no Citrix SSL server configured on the specified address.
Resolution: Refer to CTX115468 - Error: Cannot connect to the Citrix Presentation Server. There is no Citrix SSL server configured on the specified address..
Error Message: Cannot connect to the Citrix (XenApp or Presentation) Server.
The Citrix SSL Server you have selected is not accepting connections.
Reason: The Citrix server default port number might have been changed from 1494 to another port number.
Resolutions: The following are the probable solutions for this issue:
Ensure that the ipv4-port address resolution is configured on the NFuse server.
Refer to CTX104490 - Secure Gateway Does Not Support the Session Reliability Feature in Relay Mode
Check and ensure that the wfclient.ini file has the appropriate ProxyType=Auto setting.
Ensure that the STA UID listed in the Access Management Console and Secure Gateway Configuration Wizard is valid. An in-place upgrade of Presentation Server 4.0 to Presentation Server 4.5 or XenApp 5.0 modifies the UID value in the CTXSTA.config file. Reconfigure a valid STA using the Secure Gateway Configuration Wizard and the Access Management Console.
Note: For Presentation Server 4.0 and later, append the :<port number> entry for the XML Service port, which must match the STA port.
Use other standard troubleshooting methods, such as telnet, to ensure that the port 1494 is open between the Secure Gateway or Access Gateway and the XenApp or Presentation servers.
Apply the Hotfix SGE300W008 - For Citrix Secure Gateway 3.0 Hotfix.

This issue only occurs when using Internet Explorer with NetScaler. When NetScaler performs Client Certificate authentication, the SSL Handshake between the client and server fails if the protocol used is TLS 1.2.

Scenarios tested where Client Certificate authentication succeeds:

• Using IE8, IE11 and Edge with TLS 1.2 and SHA256 signed certificate – Client Auth set to Optional or Mandatory.
• Using IE8, IE11 and Edge with TLS 1.2 and SHA1 signed certificate – Client Auth set to Mandatory.
• Using Chrome with TLS 1.2 and SHA1 signed certificate – Client Auth set to Optional or Mandatory.
• Using IE8, IE11 and Edge with TLS 1.0 or 1.1 and SHA1 signed certificate – Client Auth set to Optional or Mandatory.

Scnearios tested where Client Certificate authentication fails:

• Using IE8, IE11 and Edge with TLS 1.2 and SHA1 signed certificate – Client Auth set to Optional.

NetScaler builds tested:

• NS 11.1 51.21
• NS 11.1 49.16
• NS 11.0 64.34

When a client connects to NetScaler Gateway, an SSL handshake is performed. The client sends a Client Hello to NetScaler.

The Client Hello message contains the TLS protocol and cipher suites the browser can support.

The message back from NetScaler, Server Hello agrees on a TLS protocol and cipher suite that is supported both by the client and server.

The NetScaler then requests the client to identify itself by form of certificate.

The certificate is sent from the client over TLS 1.2. However notice the following:

Certificates Length: 0 – This indicates no certificate was actually sent by the client to the NetScaler. So, authentication fails. This behavious was witnessed using IE11, when TLS 1.2 was negotiated between browser/server and a SHA1 signed certificate from a Microsoft internal CA was being selected by the client when prompted by NetScaler to provide a certificate.

The NetScaler Client Authentication mode was also set to Optional. This means because the certificate was not sent to NetScaler in the first instance, the client is not asked again and fails certificate authentication. At this stage the client does a GET request to NetScaler for the index.html page. The session uses TLS 1.2 however client certificate authentication has failed and the user will have to authenticate by other means.

The following behaviour is noted when using the same SHA1 certificate, IE11 and NetScaler Client Authentication set to Mandatory. The first handshake occurs.

TLS 1.2 with the TLS_RSA_WITH_AES_256_CBC_SHA Cipher Suite is agreed upon.

Now the client and server both fail the SSL handshake with a Handshake Failure fatal alert.

Citrix Receiver Cannot Connect To Server 40 Stations

However with Mandatory, certificate authentication must be successful so a client/server renegotiation takes place.

Citrix Receiver For Mac Cannot Connect To Server 40 Sta

This time, because TLS 1.2 has failed, the client advertises the TLS 1.0 protocol and cipher suites it supports. It could have used TLS 1.1 but the browser I used had TLS 1.1 unticked.

From NetScaler TLS 1.0 is agreed and the NetScaler picks cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.

The certificate is sent by the client without issue, over TLS 1.0. The session herein between client and server uses TLS 1.0.

Citrix Receiver Cannot Connect To Server 40 State

Now that we have identified that the issue relates to sending a SHA1 certificate over TLS 1.2 with IE, you could within IE disable TLS 1.2. This is not recommended however because all subsequent websites you visit using IE will never use TLS 1.2.

Instead, you can disable TLS 1.2 at the NetScaler Gateway vServer level.

If you are using an SSL Profile, disable TLS 1.2 in the profile that is attached to your NetScaler Gateway vServer instead. The SSL Profile is used to configure such settings rather than editing SSL Parameters on the NetScaler Gateway vServer.

The best fix though is to upgrade internal certificate authorities to sign certificates using sha265 as below. SHA1 is now deprecated publicly with internal only being supported for now to give administrators time to re-issue all internally deployed certificates.

See https://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-sha1-certificates.aspx