TLS 1.0 at the Payment Load Balancer

Likely cause

The mobile OS update dropped TLS 1.0/1.1 and RSA key exchange, and modern certificate validation requires subjectAltName. The listener offers TLS 1.0-1.2 with RSA and CBC; the certificate has CN but no SAN. The app therefore fails during handshake or certificate validation. The wildcard name may be correct, but CN-only certificates are rejected by current iOS/Android trust stores.

Modern listener

• TLS 1.2 minimum, preferably TLS 1.3; disable TLS 1.0/1.1.
• Prefer ECDHE with AEAD suites: ECDHE-RSA-AES-GCM or ECDHE-ECDSA-AES-GCM; disable static RSA, CBC-only, and 3DES.
• Use at least 2048-bit DH or P-256 ECDHE; remove 1024-bit DHE.
• Install a certificate with SAN entries for every name, a SHA-256 signature, and a chain that does not rely on legacy intermediates.
• Enable OCSP stapling and keep CRL checking as a fallback; do not disable revocation checking globally.

Verification

Test with the updated wallet, an older OS, and a protocol scanner. Check that the handshake selects an AEAD suite and that the SAN matches. The mobile failure is evidence the old listener was already noncompliant, not a reason to re-enable TLS 1.0.

Separate the risk

Do not re-enable TLS 1.0 on the main listener. Create a dedicated legacy VIP or listener with only the legacy merchant source ranges, a separate certificate, and a documented exception. Put it behind a proxy that terminates the legacy handshake and re-establishes a modern TLS 1.2+ connection to the payment application, so 3DES and RSA key exchange exist only on the short external segment.

Compensating controls

• Restrict the legacy listener by merchant IP allowlist and geo/firewall policy.
• Rate-limit and monitor for anomalous volumes; 3DES and RSA key exchange are deprecated and have known weaknesses.
• Require the merchant to attest a dated terminal replacement plan; set a hard cutoff, for example one quarter, with a kill date.
• Keep the legacy certificate and key separate from the main wildcard; do not let the legacy endpoint authorize general payments.

PCI 4.0

PCI DSS requires strong cryptography and prohibits TLS 1.0 for new implementations; legacy exceptions need documented risk mitigation and a migration plan. The assessor will want evidence that the main listener is clean and that the legacy path is isolated, monitored, and shrinking. If 15% cannot migrate, the processor should consider a managed terminal replacement or a hosted payment page to remove the dependency.

Certificate

Replace the CN-only wildcard with a certificate containing SANs for every merchant-facing hostname. A wildcard covers one label only; confirm that api.payments.example.com and pay.payments.example.com are both included or use explicit SANs. Use SHA-256 and a chain anchored in current trust stores. Enable OCSP stapling so mobile clients get revocation status without a separate lookup.

HSTS

HSTS tells browsers to use HTTPS only for a period. Enable it first with a short max-age, for example 300 seconds, on a canary host, after confirming every subdomain and redirect path supports HTTPS. Then raise to six months and one year. Add includeSubDomains only after inventory confirms no HTTP-only internal or partner host under the domain; otherwise you will break them for the max-age duration. Preload is a one-way commitment and should come last, after months of clean operation.

Risk of early HSTS

If a legacy merchant or internal tool uses HTTP or a self-signed certificate on a subdomain, HSTS will make it unreachable and users cannot click through. HSTS does not fix the TLS 1.0 listener; it only forces HTTPS. Pair it with the modern listener, SAN certificate, and redirects, and keep a rollback plan before increasing max-age.