Wildcard TLS, Missing Intermediate, and a New Partner Hostname
A SaaS provider terminates TLS for *.example.com on a Citrix ADC MPX pair. The certificate is a wildcard cert with a complete chain that expires in 21 days. A new partner integration requires portal.partner.net to be served on the same VIP and port 443. The partner will not accept a redirect to another hostname. Meanwhile, support reports that Android 7 devices fail the TLS handshake with SSL_ERROR_BAD_CERTIFICATE or certificate chain incomplete, while Windows 10 and macOS browsers work. openssl s_client -connect vip:443 -servername app.example.com shows only the leaf certificate in the server response, not the intermediate. The ADC has one certkey bound to the SSL vserver. The team wants to rotate the expiring wildcard certificate with no downtime and no change to the VIP. They have a 30-minute change window and a maintenance page available on a separate HTTP vserver.
1. Diagnose the Android handshake failure and describe how to correct the chain on the ADC.
Read the worked answer
openssl s_client showing only the leaf means the ADC is not sending the intermediate certificate. Desktop browsers often fetch missing intermediates via AIA or have them cached; Android's trust store is stricter and fails the chain. The fix is at the certkey, not the cipher list. Create or update the certkey so the certificate chain includes the leaf plus the issuing intermediate(s) in order, using the certkey chain parameter or a PEM bundle that contains the leaf and intermediates. Do not include the root if the client already trusts it. After binding, show ssl certkey should show the chain, and openssl s_client -showcerts -servername app.example.com -connect :443 should return the leaf and the intermediate. Also check that the intermediate is the correct one for the leaf issuer and that it has not expired.
2. Design the SNI configuration for portal.partner.net. What certificate is required, how is it bound, and how do you verify it?
Read the worked answer
The wildcard *.example.com cannot match portal.partner.net, so SNI must select a different certificate. Obtain a certificate whose CN or SAN is exactly portal.partner.net from a CA the partner trusts. Add it as a separate certkey, bind it to the same SSL vserver, and enable SNI on that vserver (set ssl vserver -snienable ENABLED). When the partner client sends the SNI name, the ADC selects the partner cert; clients that do not send SNI receive the default certificate, which is the wildcard and will fail for the partner name. Therefore confirm the partner supports SNI; if it does not, use a separate VIP. Verify with openssl s_client -servername portal.partner.net -showcerts -connect :443 and check the subject/SAN and chain.
3. Plan the zero-downtime rotation of the expiring wildcard certificate. Compare updating the existing certkey with binding a new one, and give a safe sequence.
Read the worked answer
Safest sequence: upload the new wildcard certkey under a new name with its key and full chain; bind it to the SSL vserver; verify with openssl s_client for several *.example.com names and check the chain and expiry; then unbind the old certkey and remove it after a rollback window. Existing TLS sessions are not torn down by the rebind, and new connections use the new certificate. The alternative-update ssl certkey on the existing object-can be atomic and avoids a bind/unbind, but a mistake in the key, chain, or password affects live traffic immediately. If you use it, stage the files and test on a non-production vserver first. In either case, keep the maintenance page ready, monitor show ssl certkey and the vserver SSL stats, and do not delete the old certificate until the new one has been verified from an external client.