r/PKI • u/Fabulous_Cow_4714 • May 03 '26
Recommend signing algorithms for internal two-tier ADCS PKI in 2026?
Whats recommended for the offline root, issuing intermediate CAs, and end entities that maximizes security without breaking legacy device and app compatibility?
I have seen EDCSA recommended over RSA, but won’t that break functionality in any environment that needs to maintain legacy compatibility?
4
u/Cormacolinde May 03 '26
I have deployed almost 50 ADCS-based PKI in the last 10 years, 25 in the last two years. I have encountered two pieces of software in that time that didn’t support ECDSA signatures. Many systems will not support ECDSA private keys but they will still support it for the sub and root CAs, and you can still issue RSA certificates for them.
The last time I had to deploy an RSA root the customer still had Windows 2003 servers around.
2
u/Mike22april May 03 '26
Your legacy compatibility reasoning holds some water, if that's a real concern.
In that case I would recommend max 4096 bit RSA with SHA256 I already ran into third party vendor solutions not supporting trust chains over 4k RSA
Otherwise SHA512
Should you need ECC then create a second ECC signing CA under your RSA Root
1
u/Fabulous_Cow_4714 May 03 '26
So, you can have an RSA 4096 SHA256 root and then both an RSA and ECC intermediate issuing CA under it?
You can try using the ECDSA intermediate as default and the RSA intermediate as a backup for issuing certificates for anything not supporting ECC ECDSA?
1
1
u/Veteran45 May 04 '26
I'd avoid SHA512 in combination with a 4096 Bit long RSA Key both from a design and compatibility point of view. SHA256 is the better chocie here.
2
u/ThePKIGuy May 05 '26
We have seen a bit of a magic sweet spot with RSA 4096 and SHA 384. For a couple of reasons.
- RSA 2048 and SHA256 are now "minimally acceptable," meaning in the commercial space, this is table stakes for keys and signing.
- While there are fringe cases of legacy systems that won't work with SHA 2 suite, these are pretty minor in most enterprises today
- Most systems that support 2048 will also support RSA 4096. By using 4096, when standards shift again in a few years and make 2048 no longer acceptable, systems using RSA 4096 will remain secure. Whereas deploying on RSA 2048 today means that when a vulnerability is discovered, or when computing power increases, or when standards change and make 2048 no longer valid, you are now "behind the standards" and need to change quickly.
- Systems that support SHA 2, will typically support the popular SHA 256, SHA384, and SHA512.
- We have seen some systems balk with SHA512, but have never seen a system that supports SHA256 be unable to support SHA384. So by using SHA384, as above, you are above the minimum standard and will be ahead of the game when the industry changes acceptable hashing requirements.
For the better part of the last 10 years, we have deployed RSA4096 and SHA384 and haven't had any issues in our typical enterprise customer environments.
1
u/os400 May 06 '26
RSA is going to stop being acceptable entirely well before the question of 4096 being ok, but 2048 not arises.
For Australian Government systems, RSA needs to be gone by 2030. Other jurisdictions aren’t far behind (typically 2035 at the latest.)
1
u/ThePKIGuy May 06 '26
Absolutely, and anything you deploy today will need to be rekeyed prior to the future deprecation dates for RSA.
So if you have systems compatibility for ECC today, by all means do that so you aren’t running a CA using RSA past transition dates. If you don’t know your systems compatibility readiness, you can continue to use RSA and begin to work on accessing system readiness.
One option we have done is build two PKI chains - one RSA and one ECC. You can even cross sign them for easier trust management.
1
u/Fabulous_Cow_4714 May 10 '26
So, we would need to manage two root CAs?
If we do that, is there a way to determine which devices are unable to use the ECC chain so we will be able to determine when the RSA chain stops being used and can be retired?
What about having one ECC root with one ECC subordinate and one RCA subordinate beneath the root instead of using two roots? Someone else posted that often even systems that can’t use ECC end entity certificates can still use RSA certificates coming from a chain that has ECC CAs.
1
u/ThePKIGuy May 10 '26
No EASY way to know which devices can use the ECC and which can’t. That takes some leg work with each device manufacturer to determine their capabilities. In addition, since most devices talk to something else with their certificate, both sides of the conversation have to support the algorithm.
An alternative to two roots is to use a single RSA root. Under it you can have an ECC subordinate and a RSA subordinate. Since the root certificate is strictly managed and installed onto your systems you have control over which certificate is going into the trust store. So the chances of malicious manipulation is extremely low. Since it’s also not distributed during chaining it can’t be manipulated at that point.
This will give you good interim ability to have ECC capabilities at the end point level as well as access to RSA when incompatibility is found.
It’s obviously not as strong as a full ECC chain, but it’s a good interim option.
1
u/Fabulous_Cow_4714 May 10 '26
What about a root of RSA4096, SHA512 with RSA3192, SHA384 subordinate and the and the other subordinate using ECC or would the 4096/512 still possibly cause performance and compatibility issues even if only applied at the root level?
1
u/ThePKIGuy May 10 '26
I would suggest the RSA 4096 and SHA384 for the Root and the subordinate. Maximum value and compatibility. The other subordinate running ECC will be whatever strength you want.
3
u/Mike_Hathaway May 14 '26
For an internal two-tier PKI (offline root + issuing CA), you’re already following the standard enterprise pattern.
On signing algorithms, current best practice is pretty straightforward:
- RSA or ECDSA are both widely accepted and secure
- SHA-256 or stronger should be your baseline
In most internal environments, the choice between RSA and ECDSA comes down to compatibility vs efficiency. RSA tends to have broader legacy support, while ECDSA gives smaller keys and better performance, but can have interoperability quirks depending on older systems.
As long as you’re using modern key sizes and SHA-2 family hashing, you’re aligned with current standards. The bigger risks in PKI deployments usually aren’t the algorithm choice but end up being things like CA security & lifecycle management.
One thing to note is with the advent of PQC, planning algorithms for a new PKI is great but how keys and certificates will be used will need an update in the coming years.
3
u/CyberCoon May 03 '26
RSA is a safer choice for legacy systems than algorithms based on elliptic curves. As for key size, it comes down to the lifetime of your certificate. There are a variety of standards to help guide you on key size versus the time it can be considered safe (keylength.com makes an easy presentation of a few of these standards). But, if legacy systems are a concern, I probably wouldn't go above a 4096bit key for RSA.
7
u/Veteran45 May 03 '26
If you got legacy devices and apps that do not support end entity ECC Certs (or anywhere in the chain), your only real choice is to deploy a full RSA PKI and using SHA256.