pfSense

Excluding the CA serial from being used in future, in authorityKeyIdentifier, does not solve the immediate problem with existing certificates becoming invalid. But it could perhaps be implemented now so in future using random serials could be easier.

Perhaps it could be limited to CA serial only. It seems to be having a domino effect if it is changed. More and more people with aging CA certificates will hit this problem. It took me a while to understand why the renewed CA certificate from pfSense GUI did not allow connections anymore.

There is also a lot of confusing information in forums. For example this post claims the CA certificate can be renewed in place and suggests new certificate should just be given to clients only: https://forum.netgate.com/post/967192 : but this is clearly not the case right now.

What would be the worst issue if same serial is used for CA?

Evren Yurtesen wrote in #note-2:

Excluding the CA serial from being used in future, in authorityKeyIdentifier, does not solve the immediate problem with existing certificates becoming invalid. But it could perhaps be implemented now so in future using random serials could be easier.

I agree, that's why I suggested we look into both. Though messing with AKID may not end up being feasible.

Perhaps it could be limited to CA serial only. It seems to be having a domino effect if it is changed. More and more people with aging CA certificates will hit this problem. It took me a while to understand why the renewed CA certificate from pfSense GUI did not allow connections anymore.

CA serial or intermediate serial would be the only ones that matter. Server and user certs should never reuse a serial number -- you'd have no way to revoke a bad one. Which is part of why it's also bad for a CA, though usually if a CA needs revoked the whole thing would need redone anyhow.

It's not pfSense that cares in that instance it's the clients and browser. Firefox and others refuse to allow a certificate to reuse the serial and since the GUI cert is self-signed it's effectively both a CA and a server cert. The same rules don't apply there as they would for a CA which signs multiple certs.

There is also a lot of confusing information in forums. For example this post claims the CA certificate can be renewed in place and suggests new certificate should just be given to clients only: https://forum.netgate.com/post/967192 : but this is clearly not the case right now.

That thread was before the other change was made, so at the time it was likely true since the CA serial wouldn't have changed on renew.

What would be the worst issue if same serial is used for CA?

It's more about what we don't know than what we do know. Some client software is pickier about it than others. Technically you're supposed to change serials when renewing but it's not clear in the specs if that applies to CAs as well as certs or just certs.

Adding an option to retain the CA serial when renewing should be OK so long as it isn't a self-signed server certificate type situation as with the GUI cert, and the GUI doesn't have a way to generate one of those at the moment anyhow. So the code just needs to make sure the function that generates the self-signed GUI cert gets a new serial, but for regular CA entries it should be optional.

Tested on

22.05-DEVELOPMENT (amd64)
built on Thu Apr 14 06:20:52 UTC 2022
FreeBSD 12.3-STABLE

and it works, but it doesn't prevent the user from reusing the serial and renewing the GUI cert. Maybe remove the option in that case or at least provide a warning?