Mobile TLS failures after a certificate renewal on a multi-tenant SSL vserver
A healthcare SaaS provider terminates TLS for 38 customer hostnames on one Citrix ADC MPX 8905 running 14.1. The SSL virtual server is bound to a wildcard certificate for *.medapp.example and a separate certificate for partner.health.example. The ADC is the only TLS endpoint; backends are HTTP. After a certificate renewal, desktop browsers connect normally, but Android 9+ and a Java-based integration client fail the handshake. The integration client log shows 'unable to get local issuer certificate'. The new leaf certificate was installed with add ssl certKey and bound to the vserver, but the intermediate CA certificate was only placed in the Windows trust store, not on the ADC. The partner certificate is also bound, but SNI is not enabled on the vserver. The team wants to complete the renewal without breaking the 1,200 concurrent mobile sessions and without exposing weak ciphers.
1. Explain the mobile and Java failures and the correct certificate-chain fix.
Read the worked answer
The failure is a chain-building problem, not a cipher problem. The ADC is sending only the leaf certificate. Desktop browsers often have the intermediate cached or can fetch it through AIA, so they appear to work. Android and the Java integration client do not reliably do that, so they report that they cannot get the local issuer certificate.
Install the intermediate CA certificate on the ADC, then link the leaf to the intermediate so the vserver presents the full chain. The leaf remains the server certificate; the intermediate is linked beneath it. If there are multiple intermediates, link them in order. The root is usually not required because clients already trust it, but follow the CA's guidance for the specific chain. Bind the resulting chain to the SSL vserver and verify with show ssl certKey and an external test such as openssl s_client -showcerts -servername <hostname> -connect <vip>:443.
Perform the change on a maintenance vserver first if possible, then update the production vserver. Confirm that mobile and Java clients complete the handshake before declaring the renewal complete.
2. Why is the partner hostname still returning the wrong certificate, and how should the vserver serve multiple certificates?
Read the worked answer
The vserver has multiple certificates bound, but SNI is not enabled. Without SNI, the ADC cannot select a certificate based on the hostname in the TLS ClientHello, so all clients receive the default certificate, which is the wildcard certificate. Browsers may mask this if the name mismatch is not obvious, but the partner integration will fail certificate validation.
Enable SNI on the SSL vserver, keep both certificates bound, and designate the wildcard certificate as the default for clients that do not send SNI. Test each hostname explicitly with openssl s_client -servername partner.health.example and with a client that does not send SNI. If a non-SNI client must reach the partner hostname, give it a separate VIP or a certificate that covers both names; SNI cannot help a client that does not send the server name.
After enabling SNI, verify that the certificate selection is correct for all 38 hostnames and that the chain is complete for each certificate. Monitor handshake failures by vserver during the change window.
3. The security team wants TLS 1.2 or higher only, but the Java integration client only supports TLS 1.0. What is the defensible design?
Read the worked answer
Do not lower the entire multi-tenant vserver to TLS 1.0 to accommodate one integration client. That would expose all 38 hostnames and 1,200 mobile sessions to a deprecated protocol.
Create a separate SSL vserver on a dedicated IP address and port for the legacy integration, bound to its own certificate and a restricted SSL profile. Limit source access with a network ACL or firewall rule so only the partner's known egress addresses can reach it. Enable only the minimum protocol and cipher set that the client requires, log connections, and set a dated remediation plan for the partner to move to TLS 1.2 or higher.
On the main vserver, use an SSL profile that enforces TLS 1.2 and TLS 1.3 with strong ciphers and disables known-weak options. Validate with a TLS scanner and with application tests from Android, iOS, desktop, and the Java client. If the business cannot accept a separate legacy endpoint, the alternative is to require the partner to upgrade before the renewal, but that is a business decision, not a reason to weaken the shared listener.