Renew Citrix Access Gateway SSL certificate

Ahhh… the time has come to replace those SSL certs on your CAGs.  Well most of the time we forget that the CAGs actually act as your CSG (Old School Citrix Secure Gateway) and your external sites are most liketly set up as “Gateway Direct” and pointing your return traffic to your CAG.  Meaning if your SSL cert expires, you can kiss those XenApp/XenDesktop connections good bye.

Keep one thing in mind… your SSL certs do not need to be on your Web Interface boxes (common misunderstanding that I hear all the time).  If you have NetScalers you can do SSL Offloading, but will not get into that now.

Luckly the process is really simple, if you google this, you may get confused with the OPENSSL conversion process, etc.  Here is what you need to do.

    • Generate the CSR on any IIS server via the IIS Certificate Wizard (not the CAG)
    • Send the CSR to your CA (Thawte, Verisign, GoDaddy, etc),
    • Import the certificate received from your CA via the certificate wizard to the same IIS box you used.
    • Export the certificate (including the private key! ) via the MMC Certificate Snap-in into a .pfx file and password protected if needed.
    • Convert the .pfx file to .pem format using OPENSSL – You can follow these steps (good luck!)
    • Or use a a tool developed by the OpenSSL Project called PFX2PEM which will simply allow you to drop the .pfx file into a .wds script which will convert it to PEM. Follow this link to get the tool and also read a bit on the the process (really simple)
    • Once you extract the file to .pem, import the file onto your CAG.
    • In addition, depending on the CA, you may need to upload their intermediate certificates as well.

The pem and root certs are managed on the Administration tab of your CAG

Access Gateway 5.0.4 Fail-over configuration

Since it seems the Access Gateway (CAG) will stick around (5.0.5 in the works), I decided it is worth investing the time to fully understand how the new CAGs handle failover.  There is a good deep dive article by Citrix on this, if you are still CAGing, I suggest you read it, as many things have changed since the 4.6.x (black screen) days.

The best feature (I think) is that sessions stay in sync, meaning users don’t get disconnected when fail-over occurs!

To test fail-over on this config, I’m using the default network interface for the appliance fail-over, if you run a VPX, you can simply add virtual interfaces as needed.  If you have physical appliances, you can deploy the CAGs with a single interface, which frees up a port and dedicate it for fail-over which it is recommended by Citrix.

When you’re setting up Failover on the CAGs, both appliances must run the same version of the firmware, in addtion, the admin account must match on both appliances since that part of the config is not replicated.

With two appliances joined as a failover pair, you can NAT your external IP or internal traffic to a shared virtual IP (VIP) instead of the real eth0 or eth1 IP address.  (If you have NetScalers, I would disregard this and run AGEE, however you can also load balance CAGs, but then you may run into some SourceIP fun and will add complexity to your deployment).

You need to define one virtual IP address that users will connect to and another virtual IP address which CAGs use when communicating with back-end resources. The internal and external virtual IP address can both be the same as in the example below which is using VPX appliances which are very inexpensive.

Primary VPX :

Log in to your Primary VPX, under Management Node select Networking and check Application Failover.

Primary CAG

Application Fail-over node will be available and here you’ll need to provide some information.

Appliance Failover Role : Primary
Shared key : Your Private Shared Key
Peer IP Address : The address on you secondary VPX
Internal virtual IP : Internal and External can be the same address (this can be the same depending on your environment)
External virtual IP : Internal and External can be the same address (this can be the same depending on your environment)

CAG Failover config

Click Save then on Start, then restart the appliance. You’ll now be able to access your CAG from the external virutal IP address you configured.

Secondary VPX :

Head over to your secondary CAG and click on Appliance Failover.  Enter the Shared Key, the Peer IP address (the Primary VPX), click Join Primary and reboot the appliance when the button turns red.

Secondary CAG Failover

On the secondary appliance most of the configuration pages will become unavaiable, since it inherits configuration settings from the primary VPX. This includes host name, certificates, authentication profiles and so on.

Secondary CAG failover

The easiest way to test the configuration is add a host address (C:\Windows\System32\drivers\etc\hosts) with the internal/external virtual IP address to your  and then shut down the Primay VPX. If you get the following error 401 – Unauthorized: Access is denied due to invalid credentials you’ll need to change the host file on you Web Interface server to point to the new external virtual IP address.