We have recently been locking down systems to protect from the DROWN Attack vulnerability. This process involves removing the insecure SSL protocols and SSL ciphers and has generally been straightforward.
Today when locking down a Citrix NetScaler 11.x VPX appliance with a locally installed Web Interface we kept running into the issue with the blank AGESSO.JSP file after logging into the web site. This is a reasonably common issue, with lots of solutions, none of which worked today. It was eventually narrowed down to missing the following cipher on the NetScaler Gateway Virtual Server: SSL3-DES-CBC3-SHA. With this cipher missing, the Java Web Interface running on the Citrix NetScaler appliance didn’t trust the installed NetScaler Gateway.
The output from SSL Labs showed the following differences:
Without the SSL3-DES-CBC3-SHA cipher included:
With the SSL3-DES-CBC3-SHA cipher included:
So it sounds like the NetScaler Web Interface is still running Java 6.x that doesn’t trust the Access Gateway.
So my new best practice for the SSL ciphers on a NetScaler Gateway VPX (running version NetScaler Build 11.0-65.31 or later) are the following:
bind ssl cipher vpx-cipher-list
bind ssl cipher vpx-cipher-list -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
bind ssl cipher vpx-cipher-list -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
bind ssl cipher vpx-cipher-list -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384
bind ssl cipher vpx-cipher-list -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256
bind ssl cipher vpx-cipher-list -cipherName TLS1-ECDHE-RSA-AES256-SHA
bind ssl cipher vpx-cipher-list -cipherName TLS1-ECDHE-RSA-AES128-SHA
bind ssl cipher vpx-cipher-list -cipherName TLS1.2-AES256-GCM-SHA384
bind ssl cipher vpx-cipher-list -cipherName TLS1.2-AES128-GCM-SHA256
bind ssl cipher vpx-cipher-list -cipherName SSL3-DES-CBC3-SHA
I’m working to setup Citrix XenMobile 10.3 with Android for Work in the office. I’ve been working through this set of documentation from Citrix here. After Citrix enabled their side of the configuration and it correctly shows in my Google Admin console, when I try to add the Android For Work settings to XenMobile there are number of things that are strange:
- There are only prompts for the Domain Name, Domain Admin Account, and Service Account ID. There is no option for the Binding Token as shown in the screenshots.
- Once I enter this information I get the following error message “Enterprise Service Account Key is not found. Please check the configuration values.”
There is currently no XenMobile 10.3 specific information, so I don’t know if this is a change specific to 10.3 or a bug in 10.3.
Are you seeing this same error message? How did you get around it?
We have a case open with Citrix Support. They are currently trying to duplicate the problem on a clean system, so hopefully I should know more later today if it is a bug with the newest version of software or something we did incorrectly with the setup. Since the Google web pages have changed the Citrix documentation is out of date, so there might be some steps missing now that Google’s process has changed.
UPDATE 1/13/2016 4:37 PM UTC:
From Citrix Support: “We have been able to confirm the errant behavior and are currently engaged with engineering on a fix. We believe that the issue centers around the changes implemented on the Google Api site, as it does not seem to generate the service account details in the same format. I hope to have an idea by EOB if this is actually the case, or if we can come up with a workaround for the problem. Thanks!”
UPDATE 2/4/2016 11:28 PM UTC
Unfortunately I don’t have a fix that I can provide directly for this. Based on the case we had open with Citrix support it sounds like Google’s API changed breaking this functionality. Through a combination of additional undocumented steps and changes on the Citrix back end they were able to get this working.
During a recent troubleshooting session with a Citrix XenApp 5 server, I wanted to make sure that the server included the recommended hotfixes. But when trying to run the downloaded .MSP file the following error was displayed:
- Windows Installer Error applying transforms. Verify that the specified transform paths are valid.
Windows Installer Error applying transforms. Verify that the specified transform paths are valid.
This happened over and over with every hotfix downloaded. This server had originally been deployed via System Center Configuration Manager 2007 (SCCM 2007) and I was wondering if the installation cache files had been removed and needed to be downloaded from the distribution point again. The files were correctly in place, but the hotfix wouldn’t run.
Eventually I bypassed the transform file completely by temporarily renaming the “Transforms” value under the following key to “Transforms.old”:
After that was renamed I was able to successfully install the hotfix, restart and rename the registry key back to the original value.
Note: This article also posted to my work blog here.