Migrating an Internal CA from RSA to ECDSA Without Breaking Legacy Clients
You administer a two-tier internal PKI for 3,000 Linux hosts and 500 Java services. The root CA is offline; the issuing CA is an HSM-backed intermediate with a 10-year RSA-4096 key. TLS certificates currently use RSA-2048/SHA-256 and are validated by clients including Java 8u292, embedded ARM devices with mbedTLS 2.16, and curl 7.81. A security review mandates moving leaf certificates to ECDSA P-256 with SHA-256 and enabling OCSP stapling, while keeping the RSA intermediate to avoid re-issuing the root. During a pilot, 12% of Java clients fail with 'no suitable certificate' and embedded devices fail during the handshake; curl works. The OCSP responder is reachable but some firewalled clients cannot reach it. The HSM supports ECDSA but only 20 signing operations per second. The change window is four hours.
1. Why do the Java and embedded clients fail while curl succeeds, and what would you test before repeating the pilot?
Read the worked answer
The failure is probably certificate and cipher-suite selection, not the chain signature alone. An ECDSA leaf signed by an RSA intermediate is legal in TLS 1.2, but the server can only use it with ECDHE_ECDSA cipher suites and a client that advertises an ECDSA signature algorithm and the P-256 group. Java 8u292 and mbedTLS 2.16 can support ECDSA, but their exact policy, disabled algorithms, and offered cipher suites vary by build and configuration. curl is more permissive, which explains the split.
Before repeating the pilot, capture the failing ClientHello and check signature_algorithms, supported_groups, and cipher suites. On Java, inspect jdk.tls.disabledAlgorithms, security providers, and any explicit cipher-suite override. On the embedded side, confirm whether the firmware offers ECDSA at all or only RSA key exchange. Test the server with both an RSA and an ECDSA leaf and verify which certificate is selected for SNI and non-SNI clients. Validate chain order, key usage, and OCSP stapling with openssl s_client -showcerts. The likely design is dual-certificate service: RSA for legacy clients and ECDSA for modern ones, with a clear deprecation plan for firmware that cannot be updated.
2. Design a certificate-validation approach that satisfies the OCSP-stapling mandate without making firewalled clients depend on the OCSP responder. What residual risks remain?
Read the worked answer
Use stapling at the TLS terminator: the server fetches and caches a signed OCSP response and sends it in the handshake, so the client does not need direct responder access. Enable ssl_stapling and verification on the server, monitor response freshness, and keep the responder reachable from the server network rather than from every client. For clients that do not support stapling, publish a CRL or allow a documented soft-fail path; otherwise those clients will fail even though the responder is healthy.
Do not enable OCSP must-staple everywhere at once. Roll it out after monitoring shows the server can always obtain a fresh response. Cache responses and pre-sign them where possible, because the HSM's 20 signatures per second will be consumed quickly if every connection or every client triggers a new signature.
Residual risks: a responder outage becomes a hard outage for must-staple clients; some legacy clients ignore stapling and still need a reachable CRL; and cached responses have a validity window during which a revoked certificate may still be accepted. Monitor responder latency, stapling success, and response age, and keep a tested emergency procedure to disable must-staple without disabling revocation checking entirely.
3. The HSM performs only 20 ECDSA signatures per second. How does that constrain the rollout, and what would you change?
Read the worked answer
Issuing 3,500 certificates is not the bottleneck: 3,500 signatures at 20 per second is under three minutes. The risk is online signing. If the ECDSA private key stays in the HSM and every full TLS handshake needs an HSM signature, the PKI supports about 20 new handshakes per second per HSM, less after accounting for OCSP signing and administrative operations. Session resumption reduces this, but not all legacy clients resume reliably.
Capacity-test one terminator with realistic handshake rates before a broad cutover. Separate the OCSP signer from the TLS leaf key if possible, cache OCSP responses, and enable session tickets. If a terminator cannot sustain peak handshakes, keep an RSA certificate for that high-volume or legacy endpoint, or add a second HSM and load-balance signing. Roll out in waves by client class: modern clients first, legacy clients on dual certificates, then remove RSA only after telemetry shows no ECDSA-intolerant clients. The four-hour change window should be used for configuration and pilot expansion, not for discovering HSM throughput under production load.