Allowing Random Serial Numbers (RSN) within IPA has been requested by users for a decade. One of the major reasons for it being initially requested is handling the trusted CA problem. It goes like this:
You install IPA, have your browser trust its CA and play for a while. Then you want to get serious and do it for real from scratch so you do an uninstall then re-install. Trying to load the new CA into the browser can be a pain resulting in a message like “You are attempting to import a certificate with the same issuer and serial number.” Super annoying.
The reason is a stock CA installation begins with serial number 0 and allocates along a range in order with a subject based on the REALM. A re-install will begin again at 0 and if the same REALM is used, instant conflict.
Ranges are allocated using the 389-ds Distributed Numeric Assignment plugin. It starts with a range and if a replica (clone) is created the range is split between the two. And so on as more replicas are added. This is largely invisible to IPA. It treats the CA post-installation more or less as a black box.
IPA 4.9.10 adds RSNv3 support if the version if the installed PKI version installs it.
There is a pretty big catch though: only new installs are supported. It is not possible to upgrade an existing ranged IPA installation to an RSNv3 installation. The reason for this is there is not yet a good way to handle conversion from RSN back to static ranges. If for some reason you found that RSN isn’t working for you, you’re stuck with it.
And before you ask, no, there is not yet an easy way to migrate all of IPA from one server to another beyond users and groups. It’s being worked on but there is no ETA. Ideally this will easily allow substituting a new CA with the existing one. But again, there could be dragons because how there is a CA with potentially the same name but a different signing key and you could be back at square one. We’ll work hard to avoid that.
It’s important to note that request and KRA ids are also randomized in a RSNv3 installation. It probably won’t affect you operationally but the ids and serial numbers can be huge, 128-bits (~40 digits). Not all software can handle them.
The next important step is allowing for pruning which will make technologies like ACME a lot easier to manage. Currently there is no supported way that I know of to clean up a certificate database of expired certificates. With RSNv3 pruning of them should be possible.