One virtual server, five hostnames, one wildcard certificate

Name mismatch: *.saas.example.com matches exactly one label under saas.example.com. portal.partnerbrand.com is a different registered domain, so no SAN in that certificate can match it. Because the virtual server has a single client SSL profile, that certificate is presented to every client - including the partner hostname - and the client correctly rejects it.

Handshake failures on older clients: the certificate object holds only the leaf. Browsers frequently complete the chain by fetching the missing intermediate from the AIA URL embedded in the leaf, or by caching an intermediate they have seen before, which is why Chrome and Firefox appear fine. Older Android stacks and Java clients generally do not perform AIA fetching, so they cannot build a path to a trusted root and abort the handshake. The same will happen to any client that pins or strictly validates the chain.

Correct chain: leaf certificate first, then the issuing intermediate certificate(s) in order above it. The root is normally omitted - the client already has it in its trust store, and including it inflates every handshake. Order matters: some clients present a path-building failure if the leaf is not first.

Also verify while you are there: SANs cover every served hostname, the key matches the certificate, and the expiry date. If an intermediate in the supplied chain is cross-signed, include the one that leads to a widely trusted root.

Design A - SNI-selected client SSL profiles. Obtain a certificate for portal.partnerbrand.com (or a certificate for partnerbrand.com with the appropriate SAN). Create a second client SSL profile carrying it, with its own certificate and key objects and the full chain, and attach both profiles to vs-saas. On a TLS handshake the BIG-IP reads the SNI hostname and selects the profile whose certificate covers it. Mark one profile as the SNI default - that is the certificate presented to clients that send no SNI, or send a name nothing matches. Requirements: the virtual server must be standard processing (FastL4 cannot inspect SNI), and every profile must carry a complete chain. Trade-off: precise control and easy per-hostname renewal, but more objects to manage and a fallback certificate that must still be valid for non-SNI clients.

Design B - one certificate with Subject Alternative Names. Issue a single certificate listing all six hostnames, keep one profile. Trade-off: simpler operationally; but every client sees every partner hostname, renewal couples all six names into one change window, and one late renewal breaks all of them at once.

Design C - separate virtual servers per hostname on separate addresses, or one address with a network virtual server plus iRules. Trade-off: cleanest isolation, but burns addresses and duplicates profiles and pools.

For a partner launch on a shared address, Design A is usually the best balance. Whichever you choose, the re-encryption side is separate: the server SSL profile decides what the BIG-IP presents to the pool members, and if those members also virtual-host on SNI you need to confirm the BIG-IP is sending the right server name.

Before applying:

• openssl s_client -connect 198.51.100.20:443 -servername portal.partnerbrand.com -showcerts and read the depth lines. A complete chain prints the leaf, then the intermediate, with a 'Verify return code: 0'. Today you will see the wildcard leaf and no intermediate, and a hostname warning.
• Repeat with -servername a.saas.example.com to confirm the existing hostname still resolves to the right certificate.
• Use openssl x509 -noout -text -in cert.pem to list SANs and expiry dates, and confirm that the public key of the certificate matches the private key object in use.

After applying: re-run all six -servername probes and confirm each returns the expected certificate plus its intermediate, with no hostname mismatch and verify code 0. Then test with a client that does not fetch AIA - an older Android device or a Java client - which is the failure mode you are fixing. If OCSP stapling is enabled, confirm the stapled response is present; a stapling profile pointed at an unreachable responder delays or breaks handshakes.

At renewal:

• The new file must contain the leaf and the intermediate in the right order. Renewals frequently arrive as a bare leaf, which silently reintroduces the old failure.
• The certificate must be imported into the same certificate object the profile references; no profile rebuild is needed, and new connections pick it up.
• If the key was regenerated, the matching key object must be updated at the same time. A certificate and key that do not match breaks the profile and takes the virtual server down at the next handshake.
• Existing sessions keep the old certificate until they close or renegotiate, so a spot check immediately after import may still show the old certificate - use a fresh connection.
• Schedule the renewal before the 12-day expiry, and alert on expiry independently of the automation.