A gateway certificate is renewed, the new one is installed, the browser shows the padlock — and the next morning the help desk has a queue of users whose Citrix Workspace app will not connect. A common cause is the chain: the NetScaler is sending its own certificate but not the intermediate certificate that issued it. It is not the only cause — a device that does not trust the root, or a name the certificate does not cover, fail the same way — so the first job is to see which one it is.
Why the browser works and the app does not
A certificate authority does not sign your gateway’s certificate with its root. It signs it with an intermediate, which the root signed. A client trusts the root, so to trust your certificate it needs the whole ladder: your certificate, the intermediate, the root. The root is already on the client. The intermediate has to come from the server.
When the server leaves it out, clients split into two groups. Desktop browsers often fill the gap themselves: they have seen that intermediate before and cached it, or they download it from the address written in the certificate. Many other clients do not. Citrix Workspace app on several platforms, Java and Python programs, older mobile operating systems and most command-line tools refuse the connection. So the certificate looks fine to the person who installed it, and fails for the people who use it.
Check the chain your gateway presents
Test from outside, the way your users connect, not from the appliance. The diagnosis is not how many certificates the server sends; it is whether the certificate that issued yours is among them. Read your certificate’s issuer, then look for a certificate with that subject in what the server sent. If it is not there, and it is not a root the client already trusts, that issuer is the missing intermediate.
SSL/TLS check
Type your gateway’s name. It reads the chain the server sends, follows each certificate to its issuer, and names the missing intermediate when the issuer is neither sent nor a trusted root. It also reports the expiry, whether the name matches, and which TLS versions are accepted, each with the fix.
Check your gateway →What the check keeps: the name you type is held in memory for one minute, so the same server is not probed twice in quick succession, and is not written down anywhere. Your address is held in memory for up to an hour to apply the rate limit. The only record the service keeps is a count of checks per day.
With a command line, openssl s_client -connect gateway.example.com:443 -servername gateway.example.com -showcerts prints the chain the server sent, each certificate with its subject (s:) and issuer (i:):
# before: the server sends its own certificate only 0 s:CN = gateway.example.com i:CN = Example Issuing CA 2026 ... Verify return code: 21 (unable to verify the first certificate) # after linking the intermediate: the issuer is now in the chain 0 s:CN = gateway.example.com i:CN = Example Issuing CA 2026 1 s:CN = Example Issuing CA 2026 i:CN = Example Root CA ... Verify return code: 0 (ok)
Before, certificate 0 names Example Issuing CA 2026 as its issuer and nothing with that subject follows: that is the missing certificate. After, certificate 1 is that issuer, its own issuer is a root the client trusts, and the chain validates. The SSL/TLS check reads the same way: before, it names the missing issuer; after, it says the chain reaches a trusted public root.
How to fix it on a NetScaler
On a NetScaler the intermediate is its own certificate-key pair, linked to the server certificate. Get the issuer’s certificate as a PEM file — from your CA’s download page, or from the certificate bundle the CA sent (the PFX to PEM guide shows how to take it out of a .pfx) — save it as gateway-ca-1.pem, upload it to /nsconfig/ssl/, then:
# the intermediate, as its own certKey (no key file: it is a CA certificate) add ssl certKey gateway-ca-1 -cert gateway-ca-1.pem # link your server certificate to it; the appliance now sends both link ssl certKey gateway-cert gateway-ca-1 save ns config
Some CAs issue two intermediates in a row. Each one is its own certKey, linked to the one above it: gateway-cert to gateway-ca-1, then gateway-ca-1 to gateway-ca-2. You do not need to add or link the root.
Then check again from outside. The issuer should now be in the chain and the chain should validate.
While you are there
The same check lists which TLS versions the virtual server still accepts. TLS 1.0 and 1.1 were formally retired in 2021 and current browsers no longer use them; if either is still offered, turn them off on the virtual server or in its SSL profile:
set ssl vserver gateway-vs -tls1 DISABLED -tls11 DISABLED
Making it not happen again
The intermediate goes missing because renewal is a sequence of manual steps on each appliance, and linking the CA is the step that has no visible effect in the browser you test with. Our monitoring and management platform, DTR Vantage, does that sequence for you: it finds the renewed certificate, installs it on every NetScaler that serves it, links the chain, moves every binding, reads the result back, and shows you the plan before it changes anything. See certificate automation.