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.

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.

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.