My company updated the Citrix servers, and suddenly I ran into keyboard problems. This applies to the latest version of the Linux Citrix Client (12.1).

Under Tools->Settings->Preferences there are keyboard settings. I used to leave those at Default but now I need to set them.

The tricky part is not the settings themselves – the tricky part is knowing IF and WHEN the settings have applied. When playing with those settings I suggest the following procedure:

1. Start the Citrix Client (wfcmgr)
2. Make your settings
3. Restart your client
4. Test your settings (starting applications)
5. Finally, make sure all connections are dead (Tools->Connection Center)
6. Stop the Citrix Client

If paranoid, also use ps and kill to make sure no citrix client runs. I wasted much time thinking I was using some configurations when in fact I was not.

For the keyboard settings themselves, I found I needed all of them (leaving none at default):

• Keyboard Layout=Swedish
• Keyboard Type (Client)=LINUX
• Keyboard Type (Server)=IBM PC/XT or compatible

As I dont really know the version or the settings of our Citrix Server environment, this is more some trial-and-error advice rather than a solution to your problem.

When connecting to a citrix server with the Linux client you can get this error message:

You have chosen not to trust “????”, the issuer of the server’s security certificate (SSL error 61).

Problem is that the Citrix client does not know about very many “trusted authorities”. Mozilla/Firefox knows about them though. If you have installed the Citrix ICA client in your home directory this is how to fix the problem on Ubuntu.

$ cd ~/ICAClient/linuxx86/keystore
$ mv cacerts cacerts.orig
$ ln -s /usr/share/ca-certificates/mozilla cacerts

Done! Now problem should be fixed.

If you access Windows applications via Citrix, and it is a fairly modern Citrix server chances are you can just start your Citrix receiver, give server, username and password; and voila you get your applications immediately (without the need to start a browser and log on to the Citrix portal). For me this worked easily on Windows, Android and iOS. But not on Linux. The Linux (and probably Unix) Citrix receiver (wfcmgr) has more weird features, and it is more… compliant.

PNAgent/config.xml
The key to everything is a little file:

  http://portal.mycompany.com/Citrix/PNAgent/config.xml

On all platforms except Linux/Unix you can just give Server

  http://portal.mycompany.com

but on Linux/Unix, you need to give the Server URL. Well that is kind of easy to figure out.

Connection View vs Citrix XenApp View
If you just want your applications right away, in the View menu in wfcmgr you need to switch to Citrix XenApp view. After that, start making settings under the Tools menu. I wasted hours in the useless Connection View.

Overriding in config.xml
Maybe, at this point, you are already up and running. Good for you! If not, keep reeding. In the config.xml-file, you can find the following lines:

  <LogonMethod>sson</LogonMethod>

  <LogonMethod>prompt</LogonMethod>

First one means that Single-sign-on is ok. Second one means that user/password is ok. My file did not contain the “prompt” line, nevertheless the iOS and Android app (and probably also Windows) did use the prompt mode, ignoring the policys from the file – and getting away with it (yes, Wireshark was involved at this point). But the Linux client is dead compliant, and failes with no useful error message. I really put lots of effort into running the Linux client through a NTML-proxy to get SSON – totally wasted.

So, I downloaded the confix.xml file. I replaced sson with prompt. Then I hosted the confix.xml file on my local webserver:

  http://localhost/Citrix/PNAgent/config.xml

That almost worked. But the clever (stupid!) wfcmgr then replaced all URLs in the files from portal.mycompany.com to localhost. And since I dont have a full Citrix server, it didnt find things like enum.aspx (on localhost). Well, turns out there are plenty of things like:

  <Location replaceServerLocation="true" modifiable="true" ...

that you can change into

  <Location replaceServerLocation="false" modifiable="false" ...

and then it does not destroy the URLs anymore. Now it worked!

As a final revenge I modified the following line:

  <EnableSavePassword>true</EnableSavePassword>