Seeking advice about dropping RSA from my site

I am thinking of just using ECDSA certificate and dropping the RSA certificate on my web site, any real reason not to drop RSA?

Looking on SSL Report: ( in the Handshake Simulation I do not see any of the successful Simulated Clients using RSA.

I am just looking to make my life just a little bit simpler.


Clients supporting TLSv1.2 also would have ECDSA support, so no surprise there.

I do find something interesting: you have 128 bit AES for TLSv1.3, but only 256 bit AES for TLSv1.2? You probably could increase compatibility by also including a 128 bit AES cipher for TLSv1.2 for clients not supporting TLSv1.3 and also without 256 bit AES, such as Android 5 and 6.


Given that you only support TLS 1.2+ and AEAD ciphers, you are indeed de facto ruling out ECDSA incompatible clients. So you should be able to safely drop your RSA certificate without further compatibility impact.

That being said, the best thing to do is to include the negotiated protocol and cipher in your access logs, so you can make an informed decision based on your user traffic (for future protocol/cipher upgrades).


I am not worried about compatibility that much, it is mostly just a toy site for me and I have only 1 Android device older than 8.1 and it is 4.4.4 and it works fine.


Strangely enough Android 4.4.x (SSLLabs shows 4.4.2) indeed has TLSv1.2 256 bit AES ciphers.. Why Google dropped support for that in later versions is beyond me.. (And re-enabled them in 7+..)


I know, the world doesn't always make sense. :roll_eyes:


This wasn't only a Google thing. Similar thing happend in older Firefox versions (e.g this one). Basically some library authors realized that AES-256 wasn't really worth the slower speed - especially on older ARM CPU's (which were modern on phones back then) with no real acceleration for AES(-GCM), the performance with AES-256 bit was noticeably worse than with AES-128 - and AES-256 had effectively zero value back then.

However, because servers generally choose the cipher suite, clients couldn't tell the server "please don't use AES-256, that's slow for me!", unless the client explicitly said "no, I don't support that!". So support for these "slow, big suites" was either not implemented at all, or deliberately disabled later on. Compatibility wasn't really affected, as virtually every standard TLS configuration should have included AES-128 ciphers. ChaCha also wasn't well supported initially, and logic for preferring ChaCha on non-accelerated CPU's was rarely supported on servers until vendors like OpenSSL started adding flags for that.

Hardware support for AES, as well as server-side ChaCha support, however started to get better eventually (even on ARM), and the CPUs were faster overall, so at some point in time the performance hit wasn't as big anymore. Also, the quantum people started screaming "AES-128 is not secure on a quantum system!", so the demand for enabling 256 bit ciphers came back, until eventually every vendor (re)-implemented support (again).


I have seen a client implementation with TLS v1.2 support, but no ECDSA support (Java platforms were the ECC provider was removed for some reason - they can't do neither ECDH(E) nor ECDSA). I don't have actual numbers, but in the wild ECDSA support should be pretty good nowdays. There's always some broken or buggy implementation out there where you never know how it will behave, but in terms of webbrowsers it's really uncommon.

On the email side, I sometimes see MTA's that fail DANE validation on ECDSA certs, but succeed on RSA certs - apparently some implementations didn't consider that the key type could be something else but RSA :roll_eyes:.

On the server side, I've also seen software completly refusing to accept ECDSA certificates - probably related to internal validation algorithms being hardcoded on RSA.

Though overall, for a simple webserver, ECDSA support should be good enough to not worry too much.


I've disable my RSA certificate and Cipher Suites. All tests I've run I haven't seen any of them miss the RSA.


Latest Chrome (49) on Windows XP is/was another one.



Yep, that was done when they still checked HTML 4.01. Their tool has changed since that badge was received.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.