Random Serial Numbers for the IPA CA

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.

The CA software that IPA uses, dogtagpki, recently gained support for a new RSN schema, version 3, in dogtagpki version 11.2.0 (as of this writing still in pre-release).

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s