Legacy TLS Clients, ECDSA Certificates, and PCI Segmentation
A payment platform runs BIG-IP 16.1.2 with two virtual servers. vs_payments (203.0.113.10:443) carries cardholder data and uses Client SSL profile clientssl-hardened: TLS 1.2 and 1.3 only, ECDHE cipher suites, and an ECDSA P-256 certificate. vs_telemetry (203.0.113.11:8443) uses the same profile. Roughly 1,800 industrial sensors, built in 2018 and not replaceable for nine months, post telemetry every 30 seconds. They support only TLS 1.0 with RSA key exchange, trust an RSA-2048 CA, and do not send SNI. Separately, about 3.5% of payment clients (Android 7 WebViews) now fail the TLS handshake. The payment application must remain PCI DSS compliant, which means TLS 1.2 or higher and no RSA key exchange for cardholder traffic. The telemetry feed contains no cardholder data but feeds a billing reconciliation process. Monitoring shows the telemetry virtual server has zero successful handshakes since the change, and payment handshake failures are concentrated on devices that do not support ECDSA certificates.
1. What evidence would you collect to confirm the root causes of both failures?
Read the worked answer
Reproduce from the client side and from the BIG-IP. From a Linux host, run openssl s_client -connect 203.0.113.10:443 -tls1_2 and again with -cipher ECDHE-RSA-AES128-GCM-SHA256 to see whether the failure is protocol, cipher, or certificate type. For the sensors, use openssl s_client -connect 203.0.113.11:8443 -tls1 -cipher AES128-SHA; if the ClientHello is sent and the server returns a handshake failure, the profile is rejecting the protocol or key exchange.
On the BIG-IP, check tmsh show ltm profile client-ssl clientssl-hardened for handshake failures, and grep /var/log/ltm for no shared cipher, handshake failure, and unsupported protocol. A packet capture on the telemetry VLAN with tcpdump -i <vlan> -s0 -w telemetry.pcap port 8443 shows the ClientHello protocol version and cipher list, and whether SNI is present. The payment failures on Android 7 are consistent with an ECDSA-only certificate: the device may support TLS 1.2 but not ECDSA. Confirm with an Android 7 emulator against an RSA certificate on a test virtual server. The evidence should distinguish three causes: TLS 1.0 rejection, RSA key-exchange rejection, and ECDSA certificate rejection.
2. How would you redesign the virtual servers and profiles to restore both client groups without breaking PCI compliance?
Read the worked answer
Separate the flows by IP and port, not by SNI. Keep vs_payments on 203.0.113.10:443 with TLS 1.2 and 1.3, ECDHE, and no RSA key exchange. To recover Android 7 payment clients without weakening PCI posture, change the payment certificate from ECDSA to RSA-2048 and use ECDHE-RSA cipher suites. RSA certificates are not prohibited by PCI DSS; RSA key exchange is. That preserves forward secrecy while restoring compatibility.
For telemetry, create a dedicated virtual server on 203.0.113.11:8443 with a clientssl-legacy profile allowing TLS 1.0 and RSA key exchange, bound only to the sensor source range with a network firewall or an LTM source-address rule. Do not attach the legacy profile to the payment virtual server, and do not use a single profile with TLS 1.0 enabled for both. If the sensors cannot be restricted by source, put them on a separate network segment. Add a monitor that validates the telemetry endpoint, and document the exception with a nine-month expiry so the legacy profile is removed when firmware is updated.
3. Why does the sensors' lack of SNI matter, and what validation would you perform after the change?
Read the worked answer
SNI matters because the sensors do not send it, and the payment clients may send it. If you use iRule-based Client SSL profile selection by SNI, a non-SNI client always receives the default profile. That makes a single IP with SNI multiplexing a poor fit here: the sensors would need the legacy profile as the default, which would expose payment clients that omit SNI to the wrong policy. Separate IP and port pairs avoid the problem entirely.
For payment clients that do send SNI, you can serve RSA and ECDSA certificates with SNI-based selection, but that adds complexity and does not help non-SNI devices. Verify with openssl s_client -servername and without it. Also check cipher string ordering: if ECDSA ciphers are listed before ECDHE-RSA, some clients may negotiate a suite they cannot complete. After the change, confirm with tmsh show ltm profile client-ssl that the payment profile still reports zero TLS 1.0 handshakes and that the telemetry profile accepts the sensor ClientHello.