Mobile App Trust Failure and a Second Hostname

Diagnosis

The server is sending an incomplete certificate chain. The BIG-IP client SSL profile has the leaf certificate for portal.example.com but not the intermediate CA that signed it. openssl s_client showing only the leaf and returning verify code 21 confirms that the client cannot build a path to a trusted root.

Desktop browsers often succeed because they cache intermediates from previous sites, or they use the Authority Information Access extension to fetch the missing intermediate. Mobile apps commonly use a stricter trust store and do not perform AIA fetching, so they fail with 'not trusted'. The problem is not the leaf certificate, the private key, or the TLS version; those would produce different errors. The fix is to serve the intermediate with the leaf.

Note that the root is normally not sent by the server. Clients already have the root in their trust store. The required chain is leaf first, then intermediate.

Build and install

1. Obtain the leaf certificate in PEM format and the intermediate certificate from the CA. Do not include the root in the served chain unless a specific client requires it.
2. Concatenate them in order: leaf certificate first, then intermediate, into one PEM file. The private key remains a separate file.
3. Import the chain as the certificate object used by the client SSL profile, or replace the certificate file and update the profile. Keep the same key. If the profile references a managed certificate, import the chain into that certificate object rather than creating an unrelated one.
4. If the virtual server has multiple client SSL profiles, confirm the corrected profile is the one selected for portal.example.com.

Verification

• openssl s_client -connect 198.51.100.20:443 -servername portal.example.com -showcerts should show the leaf and the intermediate, and verify return code should be 0.
• Test with the actual mobile app on a clean device or simulator.
• Check the certificate expiry and the profile's cipher settings while you are there.

Perform the change during a maintenance window or on a standby device first if the pair allows it. A profile update is immediate for new connections.

SNI design

Create a second client SSL profile for api.example.com with its own certificate and key. Attach both client SSL profiles to the same virtual server. The BIG-IP selects the profile whose certificate matches the SNI hostname sent by the client.

For clients that do not send SNI, the BIG-IP uses the profile marked as the default. The default profile's certificate must therefore be valid for those clients. If legacy clients only use portal.example.com, make the portal profile the default. If legacy clients need api.example.com, the cleanest solution is a separate virtual server on a different IP address, because a single default profile cannot satisfy two different hostnames for non-SNI clients.

Test with openssl s_client both with and without -servername. Also confirm that the API certificate chain is complete and that the cipher rules are compatible with the older clients. Do not rely on the default profile to 'fall back' to a certificate that does not match the requested hostname; the client will reject it.