Jump to content
Welcome to our new Citrix community!

Renewal of certificate breaks Windows Shortcut (commandline) access to the StoreFront environment

Recommended Posts

Greetings, I want to put a peculiar problem to the group to see if anyone might be able to shed some light on the subject. 


One of our (public CA) certificates is coming up for renewal, and by now we updated that certificate on our Windows environment. we imported the new certificate to the NetScaler VPX, the Director machines, and the StoreFront machines. On all servers running Director and StoreFront we altered the IIS bindings to use the new certificate.  


The NetScaler (version 13, build 79.41) has two load-balanced virtual servers housed, which point at the Director machines and the StoreFront machines. Both of these load balanced servers on the NetScaler were issued the new certificate. So the internal requests to both the Director and StoreFront websites with a browser are pointed at the NetScaler which selects the actual server being talked with.


Once the certificates on all devices were updated we tried accessing the load balanced IP and both the Director website and the StoreFront website popped up as expected, both identifying with the new certificate. Starting the default published desktop from the StoreFront website also worked without issue, so we assumed that the switch would be complete with that. 


So we had the following active:
* The StoreFront servers have the new certificate setup through their IIS bindings
* The Director servers have the new certificate setup through their IIS bindings
* The Load Balanced Virtual Server for Director on the NetScaler has the new certificate assigned
* The Load Balanced Virtual Server for StoreFront on the NetScaler has the new certificate assigned


However, we were then informed that on our thinclients the access to the environment stopped working. 


We present an icon on the desktop that kicks off a commandline from Citrix Workspace that connects to the URL of the store on StoreFront, and starts the offered desktop there. The version of the Workspace app on the thin clients is the 1912 LTSR, but we're not sure if that one is what is causing our grief. So the thinclient just sits there quietly.


If the thin client connects to the Load Balanced IP for the StoreFront servers via a webbrowser, the webpage pops up, and starting the actual virtual desktop can be done without problem.

In troubleshooting this we found that if the Load Balanced Virtual Server for StoreFront gets the new certificate assigned, accessing the URL for StoreFront from a webbrowser works, but the commandline tool accessing the StoreFront presented desktop does not work anymore. Once the certficate is rolled back to the old certificate, the problem for the thin clients goes away. 


So now we have the following active:
* The StoreFront servers have the new certificate setup through their IIS bindings
* The Director servers have the new certificate setup through their IIS bindings
* The Load Balanced Virtual Server for Director on the NetScaler has the new certificate assigned
* The Load Balanced Virtual Server for StoreFront on the NetScaler has the old certificate assigned


When comparing the old and new certificates there is one noticable difference (beyond the serialnumber and validity dates): The key length is 4096 on the new certficate, whereas the old one has the 2048 length. According to https://support.citrix.com/article/CTX206268 the 4096 keylength should be supported, so we're not sure what is happening here. Plus, that if the certificate was the cause, we'd somehow also expect the website (which is offered through the loadbalanced IP on the NetScaler) to have issues... which it doesn't. 


We tried looking at the logs on the NetScaler but we're both not that that well versed in the NetScaler that we're well aware what logs (if any) we can look at to potentially determine what is going on. Also, testing this would require creating a completely new virtual server on the NetScaler which we're both also not that familiar with, since if we don't create a new virtual server, any test we do would immidiatly hit our production environment for new sessions.


So, does anyone have an idea as to what might be going on here?

Link to comment
Share on other sites

It seems like the issue is with a particular client not supporting the key length or other parameter changes in the new cert and not the ADC (if I read that right).

Check the thin client's affected client logs and client support requirements, if these clients work with one cert and not the other the problem is client side (and not ADC side, if other clients are fine).


Client logs should have the connectivity issues, or you need to adjust ssl profile/cipher lists or some other change to support if they can't be upgraded/patched to work with the new cert issuance.


Link to comment
Share on other sites

From what we could discern, changing the certificate allows all thin clients to still start the offered desktop from the StoreFront store, as long as they first access the website which is offered by StoreFront. Once there they can initiate the startup of the desktop they need, and it all works. So the client doesn't seem to have an issue with the certificate. It might still be the version of the Citrix client regarding the bits on command-line starting an application tho. 


When the certificate is replaced with the new version, the shortcut icon we placed on the desktop of the thin client (which is a LOT easier for users to utilize) stops working. Once we revert to the old certificate (which will become invalid mid september), the shortcut works again. 


So it's not so much an issue of the client (both the thinclient, and the Citrix client installed on it) since that works. It's just that the shortcut behind the icon fails to do anything. 


Normally we'd expect it to pop up an authentication box which it does to authenticate the user prior to allowing them access to the StoreFront website. Once the user filled in his credentials, the command continues to select the appropriate store and the offered desktop within that store, and starts it off. So where accessing the website would require the user to open a browser, log in, and then select their desktop, the shortcut simplifies that to one double click, filling in credentials and off it goes. 


Once the certificate is renewed tho, the authentication box doesn't appear anymore, and the computer just seems to 'ignore' the doubleclick on the icon. 

Link to comment
Share on other sites

You need to look at the client logs and/or a network trace and see if you are getting client-side ssl hand shake issues related to the cert, trust, cipher negotiation etc...  There's a possibility that new cert and new ssl settings are more strict and there is a client side negotiation difference between web vs. services or explicit for passthrough authentication (if applicable).  If the  lb vserver ssl settings were also updated during the cert renewal, there may be a factor.


Or go through support.  If you have scenarios that worked before and that aren't working now that may go a long way to find issue and identifying resolution.  


Link to comment
Share on other sites

My colleague took some time yesterday for testing. He's the one that initially swapped out the certificate on the NetScaler, and did so again yesterday after hours.


He replaced the certificate on the NetScaler with the new one, and tried via a mobile thinclient from his home location via VPN. Which worked without issue. 

Verified the used version of the client (Citrix WorkSpace (1912)), and the launch command in the shortcut ("C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\SelfService.exe" -qlaunch Production).


So my colleague commandeered a fixed thinclient on location (people tend to not switch them off quite often), and tried from there. Version of the Citrix Workspace and the command behind the shortcut was the same, and this time there were no issues from that thinclient. 


We opted to leave the certificate since all tests we managed to do seem to indicate that the new certificate was now working as intended. We did keep a warning open to first-line support that the certificate had changed, so we would not be caught unaware if suddenly a multitude of people would call in reporting a problem.


This morning no issues are reported on the starting of the environment, hinting that the certificate is now working as intended. I took the time to verify the thinclient my colleague tested on Monday which did not work. Said thin client now has no issue. Verified the Citrix Workspace version and the command, and both were (as expected) exactly the same. 


Do note, we rebooted the thin client on Monday multiple times, but just couldn't get it to pop up the authentication and subsequent connection. Which today works without issue. 

Expiration and validity of the certificate have not changed, and were as valid Monday as they are today. 


So while I have no real idea what was going on on Monday, I have to admit that today everything seems to work as intended with the new certificate. So I consider this thread/question no longer active/valid. Thanks for all your input, it's appreciated. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...