- Troubleshooting Citrix Receiver On Mac
- Download Citrix Receiver For Mac
- Citrix Receiver For Mac 12 4
- Citrix Receiver For Mac 10
To whom it may concern:
Feb 01, 2016 This video will walk you through installing and configuring Citrix Receiver to work with your NorthStar network account on a Mac OS X machine If you have a.
- Nov 21, 2017 For Macs, launch Receiver then click About Citrix Receiver as shown here. Apps from Google Play/Apple App Store/Microsoft App Store should automatically update themselves. To determine the most current versions visit this citrix page and expand the button for your receiver. As of December 2017 these are the current versions.
- Mar 11, 2019 Citrix won't maintain the receiver for further versions, the receiver 12.9.1 will obviously the last version. The receiver has been replaced by Citrix Workspace App, the current version is Citrix Workspace app 1809. Download this version from the Citrix website and install it. The new app will automatically replace the receiver app.
I am a nurse practitioner student currently doing clinical at Cocoa Family Practice in Hershey, Pa. In order to be able to perform my duties at this practice, I have to be able to sign onto Allscripts Touchworks Live through the Citrix portal. I was told by IT that I had to download the Citrix Receiver which I was able to find in the app store on my phone, but there were no search results when I searched for it on my Macbook Air. What should I do?
Troubleshooting Citrix Receiver On Mac
MacBook Air (13-inch, Early 2015)
Posted on
Applicable Products
- XenDesktop
- NetScaler Gateway
- Receiver for Mac
Symptoms or Error
Users are getting Delay of approx 2 minutes, after they try to launch the XenDesktop.
From the Packet Captures collected on the Client Machine, we can verify once the Client sends the Client Hello followed by NSG Sending Server Hello along with the Server Certificate, Receiver for MAC 12 tries to perform CRL Revocation Check , which is not successful due to no connectivity with CRL Providers over Internet.
CRL Check has a timeout of 60 seconds for each URL , so if you've 2 URL's configured to perform CRL Check, that contributes to delay of 2*60 seconds = 120 seconds.
And Finally Client/Receiver resumes the SSL connection by Sending Change Cipher Spec.
Receiver Logs from MAC Machine
If we can see here MAC Client tries to contact 1st CRL URL @ 11:27:33 and times out right after 60 seconds.
And then tries second CRL URL and time’s out after another 60 seconds @ 11:29:34 before proceeding with this connection i.e. almost 2 min and 1 seconds
| 05-23-2016 | 11:27:24.945 | 1716 | 1 | sslprefs.m | 173 | GetRevocationPolicy | TC_TD | TT_API1 | Config TLS revocation policy pref: FullAccessCheck << Shows us the current setting for CRL Revocation Check>>
| 05-23-2016 | 11:27:33.057 | 1716 | 2 | sslasock.c | 614 | crlDownloadCb | TC_TD | TT_API1 | Downloading CRL from http://ss.symcb.com/ss.crl
| 05-23-2016 | 11:27:33.057 | 1716 | 2 | sslasock.c | 647 | crlDownloadCb | TC_TD | TT_API1 | Running nested run loop
| 05-23-2016 | 11:27:56.603 | 1716 | 1 | mac_NCS_appleEvents.m | 628 | HandleAppleEventsCommon | TC_RECONNECT | TT_API1 | 'odoc' event: items in list: 0, err: 0
| 05-23-2016 | 11:27:56.603 | 1716 | 1 | mac_NCS_appleEvents.m | 719 | HandleAppleEventsCommon | TC_RECONNECT | TT_API1 | 'odoc' DONE: 0
| 05-23-2016 | 11:27:56.604 | 1716 | 1 | ICAViewerAppDelegate.m | 629 | -[ICAViewerAppDelegate disableAppNap] | LOG_CLASS | TT_CONFIG | Disabling App Nap
| 05-23-2016 | 11:28:33.075 | 1716 | 2 | sslasock.c | 660 | crlDownloadCb | TC_TD | TT_ERROR | Timeout waiting for CRL download to complete.
| 05-23-2016 | 11:28:33.075 | 1716 | 2 | sslasock.c | 664 | crlDownloadCb | TC_TD | TT_API1 | Nested run loop ended
| 05-23-2016 | 11:28:33.075 | 1716 | 2 | sslasock.c | 703 | crlDownloadCb | TC_TD | TT_ERROR | response is NULL!
| 05-23-2016 | 11:28:34.103 | 1716 | 2 | sslasock.c | 614 | crlDownloadCb | TC_TD | TT_API1 | Downloading CRL from http://s1.symcb.com/pca3-
g5.crl
| 05-23-2016 | 11:28:34.103 | 1716 | 2 | sslasock.c | 647 | crlDownloadCb | TC_TD | TT_API1 | Running nested run loop
| 05-23-2016 | 11:29:32.542 | 1716 | 1 | mac_palkeyboard.m | 2491 | PALKbdHandleMacModifiers | TC_KEY | TT_API1 | mac_palkeyboard.c:PALKbdHandleMacModifiers carbonModifiers=0x100
| 05-23-2016 | 11:29:32.710 | 1716 | 1 | mac_palkeyboard.m | 2491 | PALKbdHandleMacModifiers | TC_KEY | TT_API1 | mac_palkeyboard.c:PALKbdHandleMacModifiers carbonModifiers=0x0
| 05-23-2016 | 11:29:34.118 | 1716 | 2 | sslasock.c | 660 | crlDownloadCb | TC_TD | TT_ERROR | Timeout waiting for CRL download to complete.
| 05-23-2016 | 11:29:34.118 | 1716 | 2 | sslasock.c | 664 | crlDownloadCb | TC_TD | TT_API1 | Nested run loop ended
| 05-23-2016 | 11:29:34.118 | 1716 | 2 | sslasock.c | 703 | crlDownloadCb | TC_TD | TT_ERROR | response is NULL!
The reason why these CRL download's fail or Timeout, is because the Clients in this case are behind a Network Proxy, and Receiver doesn't honors the client proxy settings to go out to internet and fetch these file's even though it should go out through Proxy.
From the Packet Captures collected on the Client Machine, we can verify once the Client sends the Client Hello followed by NSG Sending Server Hello along with the Server Certificate, Receiver for MAC 12 tries to perform CRL Revocation Check , which is not successful due to no connectivity with CRL Providers over Internet.
CRL Check has a timeout of 60 seconds for each URL , so if you've 2 URL's configured to perform CRL Check, that contributes to delay of 2*60 seconds = 120 seconds.
And Finally Client/Receiver resumes the SSL connection by Sending Change Cipher Spec.
Receiver Logs from MAC Machine
If we can see here MAC Client tries to contact 1st CRL URL @ 11:27:33 and times out right after 60 seconds.
And then tries second CRL URL and time’s out after another 60 seconds @ 11:29:34 before proceeding with this connection i.e. almost 2 min and 1 seconds
| 05-23-2016 | 11:27:24.945 | 1716 | 1 | sslprefs.m | 173 | GetRevocationPolicy | TC_TD | TT_API1 | Config TLS revocation policy pref: FullAccessCheck << Shows us the current setting for CRL Revocation Check>>
| 05-23-2016 | 11:27:33.057 | 1716 | 2 | sslasock.c | 614 | crlDownloadCb | TC_TD | TT_API1 | Downloading CRL from http://ss.symcb.com/ss.crl
| 05-23-2016 | 11:27:33.057 | 1716 | 2 | sslasock.c | 647 | crlDownloadCb | TC_TD | TT_API1 | Running nested run loop
| 05-23-2016 | 11:27:56.603 | 1716 | 1 | mac_NCS_appleEvents.m | 628 | HandleAppleEventsCommon | TC_RECONNECT | TT_API1 | 'odoc' event: items in list: 0, err: 0
| 05-23-2016 | 11:27:56.603 | 1716 | 1 | mac_NCS_appleEvents.m | 719 | HandleAppleEventsCommon | TC_RECONNECT | TT_API1 | 'odoc' DONE: 0
| 05-23-2016 | 11:27:56.604 | 1716 | 1 | ICAViewerAppDelegate.m | 629 | -[ICAViewerAppDelegate disableAppNap] | LOG_CLASS | TT_CONFIG | Disabling App Nap
| 05-23-2016 | 11:28:33.075 | 1716 | 2 | sslasock.c | 660 | crlDownloadCb | TC_TD | TT_ERROR | Timeout waiting for CRL download to complete.
| 05-23-2016 | 11:28:33.075 | 1716 | 2 | sslasock.c | 664 | crlDownloadCb | TC_TD | TT_API1 | Nested run loop ended
| 05-23-2016 | 11:28:33.075 | 1716 | 2 | sslasock.c | 703 | crlDownloadCb | TC_TD | TT_ERROR | response is NULL!
| 05-23-2016 | 11:28:34.103 | 1716 | 2 | sslasock.c | 614 | crlDownloadCb | TC_TD | TT_API1 | Downloading CRL from http://s1.symcb.com/pca3-
g5.crl
| 05-23-2016 | 11:28:34.103 | 1716 | 2 | sslasock.c | 647 | crlDownloadCb | TC_TD | TT_API1 | Running nested run loop
| 05-23-2016 | 11:29:32.542 | 1716 | 1 | mac_palkeyboard.m | 2491 | PALKbdHandleMacModifiers | TC_KEY | TT_API1 | mac_palkeyboard.c:PALKbdHandleMacModifiers carbonModifiers=0x100
| 05-23-2016 | 11:29:32.710 | 1716 | 1 | mac_palkeyboard.m | 2491 | PALKbdHandleMacModifiers | TC_KEY | TT_API1 | mac_palkeyboard.c:PALKbdHandleMacModifiers carbonModifiers=0x0
| 05-23-2016 | 11:29:34.118 | 1716 | 2 | sslasock.c | 660 | crlDownloadCb | TC_TD | TT_ERROR | Timeout waiting for CRL download to complete.
| 05-23-2016 | 11:29:34.118 | 1716 | 2 | sslasock.c | 664 | crlDownloadCb | TC_TD | TT_API1 | Nested run loop ended
| 05-23-2016 | 11:29:34.118 | 1716 | 2 | sslasock.c | 703 | crlDownloadCb | TC_TD | TT_ERROR | response is NULL!
The reason why these CRL download's fail or Timeout, is because the Clients in this case are behind a Network Proxy, and Receiver doesn't honors the client proxy settings to go out to internet and fetch these file's even though it should go out through Proxy.
Download Citrix Receiver For Mac
Solution
CRL Feature was introduced in 12.0 http://docs.citrix.com/en-us/receiver/mac/12/mac-secure-wrapper.html.
As a solution to this, we can switch over the settings of this feature to following with the following command
defaults write com.citrix.receiver.nomas SSLCertificateRevocationCheckPolicy NoCheck
NoCheck
CheckWithNoNetworkAccess
FullAccessCheck
FullAccessCheckAndCRLRequired
FullAccessCheckAndCRLRequiredAll
Please read more about them in the doc above.
But if, customer wants to use this feature as a Security Setting ,we need to make sure Receiver goes through the Proxy settings to get these file's.
To fix this issue, please open a case with Citrix Receiver Team and we can provide a workaround (private build) for this issue which has to be installed on the MAC running Receiver for 12 which will force the Receiver to send packets through Network Proxy.
Official Fix will be included in the next release for Receiver for MAC 12.
As a solution to this, we can switch over the settings of this feature to following with the following command
defaults write com.citrix.receiver.nomas SSLCertificateRevocationCheckPolicy NoCheck
NoCheck
CheckWithNoNetworkAccess
FullAccessCheck
FullAccessCheckAndCRLRequired
FullAccessCheckAndCRLRequiredAll
Please read more about them in the doc above.
But if, customer wants to use this feature as a Security Setting ,we need to make sure Receiver goes through the Proxy settings to get these file's.
To fix this issue, please open a case with Citrix Receiver Team and we can provide a workaround (private build) for this issue which has to be installed on the MAC running Receiver for 12 which will force the Receiver to send packets through Network Proxy.
Official Fix will be included in the next release for Receiver for MAC 12.
Citrix Receiver For Mac 12 4
Problem Cause
Citrix Receiver For Mac 10
This is due a known issue with Receiver for MAC 12.
As it doesn't send traffic for CRL Revocation Check to Internet through proxy and fails.
Citrix Receiver Team is working on the official fix as of now, but can provide a workaround to fix this issue for the time being.
As it doesn't send traffic for CRL Revocation Check to Internet through proxy and fails.
Citrix Receiver Team is working on the official fix as of now, but can provide a workaround to fix this issue for the time being.