How do you serve dual ECDSA and RSA certificates so each client gets the faster key it supports?

How do you serve dual ECDSA and RSA certificates so each client gets the faster key it supports?

ECDSA (Elliptic Curve Digital Signature Algorithm) certs are smaller and faster to verify, but some legacy clients lack support; RSA is the universal fallback. Serving both lets the server pick by the client's signature_algorithms. Deployment playbook.

— Obtain two leaf certs for the same hostnames: one ECDSA (P-256) and one RSA (2048-bit), each with its own chain.
— In nginx, list both with repeated ssl_certificate/ssl_certificate_key directives; the server selects based on the client's offered signature algorithms during the handshake.
— Confirm the ECDSA chain's intermediates are themselves widely trusted; a modern leaf under a poorly-distributed root negates the benefit.
— Verify selection empirically: connect with a TLS 1.3 client and inspect which leaf is returned, then repeat forcing an RSA-only client.
— Measure the handshake CPU delta under load; ECDSA's smaller signatures reduce bytes on the wire and verification cost.

Evidence vs. speculation: the per-client speedup is measurable; assuming all clients support ECDSA is the error that drops old devices.

Further reading: RFC 8446 section 4.2.3 (signature algorithms); RFC 8422 for ECDSA in TLS.

Bottom line: dual certs are an optimization with a compatibility floor, not a reason to drop RSA entirely.