Does RSA mean no forward secrecy?

Does an RSA certificate mean no forward secrecy?

No. The certificate authenticates the server, the key exchange protects the session, and they are chosen independently. RSA key exchange is the thing to remove.

Short answer: no.

The confusion is entirely down to the word RSA doing two unrelated jobs in the same handshake. One of them is harmless. The other is the thing you actually want gone.

Two different RSAs

Where RSA appears	What it does	Forward secrecy
RSA certificate	Authenticates the server. Proves you are who the certificate says	Unaffected. Works fine with ephemeral key exchange
RSA key exchange	Transports the session key, encrypted to the server’s public key	Destroyed. The session key can be recovered later from the private key

An RSA certificate paired with ECDHE key exchange gives you full forward secrecy. This is the normal, recommended configuration and probably what you already have.

RSA key exchange is the problem, because the session key is encrypted with the server’s long-term public key and sent across the wire. Anyone who records that traffic and later obtains the private key can decrypt every session they captured, retroactively. The key was never ephemeral and nothing was discarded.

Check what you negotiated

The cipher suite name tells you directly:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -i "cipher\|protocol"

Reading the result:

Contains ECDHE or DHE: ephemeral key exchange, forward secrecy present.
Begins TLS_RSA_WITH: RSA key exchange, no forward secrecy.
TLS_AES_128_GCM_SHA256 or similar with TLS 1.3: forward secrecy guaranteed, since TLS 1.3 removed the non-ephemeral options entirely.

Note that TLS 1.3 suite names do not mention the key exchange at all, because there is no longer a choice to make.

The real gap is usually the older path

Since TLS 1.3 is always forward secret, a server offering TLS 1.3 alongside TLS 1.2 or older is only exposed on the older path.

That is the case worth finding, and it is easy to miss: every modern browser negotiates TLS 1.3 and looks perfect, while an older client falls back to TLS 1.2 and lands on whatever cipher suites are configured there, which may include RSA key exchange.

So testing with a current browser tells you almost nothing about the exposure. Force the older version and see what it offers:

openssl s_client -tls1_2 -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -i cipher

What to change

Remove the static RSA key exchange suites from the TLS 1.2 configuration and keep the ECDHE ones. Your certificate does not need to change and neither does your certificate authority.

Where TLS terminates at a CDN or load balancer, this is a setting on their security policy rather than anything on your origin.

Then confirm per address, since a cipher policy applied to one node leaves the rest untouched. Forward secrecy explains the five classifications, weak and legacy cipher suites covers the other families worth removing, and certificate keys and algorithm choices covers the separate question of whether to add an ECDSA certificate.

Questions people ask

Does an RSA certificate prevent forward secrecy?

No. An RSA certificate authenticates the server and works perfectly well with ECDHE key exchange, which provides forward secrecy. What removes forward secrecy is RSA key exchange, a separate setting that happens to share the name.

Do I need to replace my RSA certificate with ECDSA?

Not for forward secrecy, which is decided by the key exchange rather than the certificate. ECDSA certificates are smaller and faster to verify, which is a reasonable performance reason to add one, but it is a different decision.

How do I tell which key exchange my server used?

Look at the negotiated cipher suite. A name containing ECDHE or DHE means an ephemeral key exchange with forward secrecy. A suite beginning TLS_RSA_WITH uses RSA key exchange and has none. In TLS 1.3 the question does not arise, since every suite is forward secret.