Wildcard Certificate Chain Fails on Android After SNI Consolidation
A Citrix ADC consolidates ten HTTPS sites on VIP 203.0.113.10:443 using SNI. The default certificate is a wildcard *.example.com installed as a leaf certificate only. Sites include www.example.com, api.example.com, and api.dev.example.com. Desktop browsers and iOS work, but Android 9 users report 'certificate not trusted' for api.dev.example.com; some Android users also see chain errors for www.example.com. Running openssl s_client with -servername api.dev.example.com returns 'verify error:num=20:unable to get local issuer certificate'. The wildcard certificate expires in 45 days. The ADC has the intermediate CA file but it is not bound. The security team wants TLS 1.2 and 1.3 only and no HTTP fallback. You must fix the current errors and propose a renewal plan.
1. Why does api.dev.example.com fail name validation even though *.example.com is bound?
Read the worked answer
A wildcard *.example.com matches exactly one label. api.dev.example.com has two labels to the left of example.com (api and dev), so it is not covered. The client sends SNI api.dev.example.com; if no certificate matches, the ADC presents the default certificate, which is *.example.com, and the client rejects the name. The fix is either a SAN certificate that explicitly includes api.dev.example.com or a separate *.dev.example.com certificate. Do not assume the wildcard covers every subdomain; it does not cover multi-level names. This is a name-validation failure, not a TLS version or cipher failure.
2. Explain the chain error and exactly what must be bound in Citrix ADC.
Read the worked answer
The unable to get local issuer certificate error means the server is not sending the intermediate CA. The leaf alone is not enough for clients that do not already cache the intermediate. On the ADC, import the intermediate CA and link the server certificate to it, or import a PEM containing leaf plus intermediate, then bind the chain to the vserver. Verify with openssl s_client -showcerts -servername <name> and confirm the intermediate appears in the presented chain. The root does not need to be sent, but the intermediate must be. Also ensure the default certificate is not leaf-only, because clients without SNI or with unmatched SNI will see it. After fixing the chain, test both www.example.com and api.dev.example.com from an Android client.
3. Recommend a certificate strategy for renewal, including SNI and the two-label site.
Read the worked answer
Renew with a SAN certificate that lists all production names, including api.dev.example.com, www, and api, or split into *.example.com for one-label names and *.dev.example.com for the dev subdomain. Bind each certificate to the correct vserver and rely on SNI; keep a valid default certificate for legacy clients. Start renewal at least 30 days before expiry, not 45 days before with no plan. After renewal, test with openssl for chain and name, test Android and an older client, and enforce TLS 1.2/1.3 with a profile. Keep the intermediate linked and document which vserver uses which certificate to avoid a repeat during the next consolidation. Automate expiry monitoring so the 45-day warning is not the first alert.