What FreeIPA random serial numbers change in the CA
FreeIPA random serial numbers (RSNv3) issue 128-bit random serial numbers to certificates from the integrated Dogtag CA, and they are the default on new FreeIPA 4.13 installations. The choice is made when the deployment is installed, not switched on later. If your IdM team is running or planning FreeIPA 4.13, you need to decide how certificate serials will be issued before the first server is built, because an existing ranged deployment cannot simply move to random serials afterward. This section explains what the feature changes, who needs to understand it, and what the rest of this page covers. The design is described in the FreeIPA random serial numbers design document, and the change was announced in the FreeIPA 4.13.0 release notes.
The main change is the serial space. Earlier ranged designs allocate serials from a sequential range, which is simple to track but predictable. A 128-bit random serial removes that sequence, so a serial cannot be used to infer how many certificates the CA has issued or to guess neighboring values. Because the serial is random, the CA and any other PKI service in the deployment must agree on it. The design requires that all PKI services, including the CA and the KRA, use RSNv3 once it is enabled. Teams that run a KRA, or that plan to add one, should confirm that it follows the same serial policy before they commit to a topology.
Two consequences shape planning. First, a ranged clone cannot be created from an RSNv3 server, so replica strategy and disaster recovery must be designed around that limit rather than assumed. Second, the 4.13.0 release notes describe automatic removal of expired certificates on new replicas after a 30-day retention period, which affects what a restored or newly added replica holds. Confirm with your own change records and the design document how these rules apply to your version and install path, and ask your implementation partner to document the serial policy as part of the CA design.
How 128-bit random serials differ from ranged serials
Ranged serials are handed out from a numeric block that each CA server reserves, which makes them predictable and easy to order. RSNv3 replaces that with 128-bit random values, and the change reaches replicas, clones, and every service that signs or records certificates. The cards below cover what changes, where it changes, and what to check before you rely on it.
Serial format and length
A ranged serial is a sequential integer taken from a block assigned to a CA instance. RSNv3 uses a 128-bit random value instead, so serials no longer climb in order and no longer reveal how many certificates a CA has issued. Any tooling that assumes serials are small, sequential or sortable needs review. Check your ticketing, inventory and monitoring fields that store serials as integers, since 128-bit values need a string or hex representation.
Where the serial is generated
In the ranged model, each CA instance draws serials from its own allocated range, so the range is the coordination mechanism between servers. With random serials, each issuing CA generates its own value at signing time and does not depend on a shared counter or block. Confirm with your own install that each CA and replica behaves this way in your topology, and record which server issues certificates for each service.
Every PKI service must follow
RSNv3 is for new installations only, and once it is in place all PKI services must use it, including the CA and the KRA. A deployment that mixes serial modes across services can produce inconsistent records. Before planning any KRA or additional PKI component, list every PKI service in your deployment and confirm its serial mode with the FreeIPA release notes and design page for your exact version.
Serial collision risk
Random values make collisions statistically very unlikely at 128 bits, but a collision is a trust problem, not only a database error, because a duplicate serial can make a revocation or lookup point at the wrong certificate. Ask the FreeIPA project how the CA detects and rejects duplicates in your version, and test that behavior in a lab before you rely on it in production. Do not assume the probability alone settles the question.
Audit and certificate lookups
Sequential serials let teams sort certificates and estimate issuance history by number. Random serials remove that shortcut, so searches for a certificate must use the full serial, subject, fingerprint or the CA database. Update runbooks, SIEM queries and revocation procedures to match. Verify that your audit log and any downstream CRL consumers handle long serial values correctly before you cut over.
Ranged clones and expired pruning
A ranged clone cannot be created from an RSNv3 server, so an RSNv3 topology cannot be extended with a ranged replica by copying the existing design. Release 4.13.0 also removes expired certificates on new replicas after a 30-day retention period. Confirm with the project how your replication and backup plan handles pruned certificates, and check which of your audit and compliance records must keep expired certificate data longer.
Choosing between random and ranged serial numbers
This table compares random (RSNv3) and ranged serial numbers across new installs, existing deployments, clones and replicas, and the cases where a team keeps ranged serials. Read each row against your current topology, then use the confirm column before you commit to a mode.
| Situation | Serial mode | What it means for replicas and clones | What to confirm before choosing |
|---|---|---|---|
| New FreeIPA installation on 4.13 or later | Random (RSNv3), the default | RSNv3 must be used by all PKI services, including the CA and KRA, so every later server in the topology follows the same mode. | Confirm your planned FreeIPA release and that every PKI service you intend to run supports random serials. |
| New installation where you need ranged serials | Ranged, set at install time | Random serials are supported for new installations only, so the choice must be made when the first CA is created, not later. | Confirm with your PKI owner whether any downstream system depends on ranged serial behavior before installing. |
| Existing deployment already using ranged serials | Ranged (keep current mode) | Ranged serials cannot simply be switched to random on a running deployment, so the existing CA continues on its current scheme. | Inventory the current serial mode on every CA server and plan any move to a new deployment as a separate project. |
| Planned ranged clone or new replica from an RSNv3 server | Random (RSNv3) on the source, clone blocked | Creating a ranged clone from an RSNv3 server fails, so ranged replicas cannot be built from random-serial servers. | Check whether any site or disaster recovery design assumes a ranged clone, and redesign that path before go-live. |
| Expired certificates accumulating on replicas | Random (RSNv3) with pruning | In 4.13.0, expired certificates are removed automatically on new replicas after a 30-day retention period. | Confirm your retention needs for expired certificate records and whether auditors or incident teams need them beyond 30 days. |
| Mixed-version topology with older servers | Depends on the install baseline | Serial mode is set by the deployment's CA, so older servers in a mixed topology must be assessed before adding RSNv3 services. | Review the upgrade path and each server's release before deciding on new services or replicas. |
| Compliance or tooling expects ranged serial sequences | Ranged (keep current mode) | Tools that rely on sequential serials may not handle 128-bit random values, so ranged serials remain the cautious choice for those integrations. | Ask each downstream consumer to confirm it accepts 128-bit random serial numbers before choosing random. |
Why existing ranged deployments cannot simply switch
RSNv3 is supported for new installations only, so a running CA that issues serials from a range cannot be switched to random serial numbers in place. The FreeIPA design for random serial numbers ties the feature to installation time. Once a deployment uses RSNv3, every PKI service in that topology must follow it, including the CA and the KRA. A mixed topology, where some PKI services issue ranged serials and others issue 128-bit random serials, is not a state the design supports. For an existing deployment, the question is therefore not whether to enable a setting but which migration or rebuild path fits the estate. Confirm that path with the FreeIPA project documentation, starting with the FreeIPA random serial numbers design, before any change is scheduled.
The practical consequence shows up in replica and topology planning. Creating a ranged clone from an RSNv3 server fails, so an RSNv3 CA cannot be used as the source for a clone that expects ranged serials. Teams that plan to add a CA replica, rebuild a site, or stand up a test copy of production from a ranged server should check whether the source and the target agree on serial handling before they script the build. This affects the order of work: the decision about serial mode has to be made before the topology grows, because retrofitting it later constrains every clone and replica that follows. Ask your integrator to map each planned replica and its PKI role against the serial mode it will need.
Before any change, confirm three things with the FreeIPA project documentation and your own environment: which migration or rebuild procedure the project currently documents for your version, which PKI services run on each server, and whether any ranged clone or replica is still planned. Record the answers in the change request. If a rebuild is the only documented path, plan for a new CA hierarchy, reissuance of affected certificates, and a cut-over window, and get the scope and effort in writing from your partner before committing to a date.
Planning a new 4.13 install with random serials
This sequence confirms that a FreeIPA deployment qualifies for random serial numbers before any server is built, then checks each PKI service and replica method so the CA serial mode is set correctly from the first install. The result is a documented plan and a verified CA configuration that can be carried into the build.
Confirm the version and that the install is new
The platform owner checks the FreeIPA version on the intended server and confirms that this will be a fresh installation, not an upgrade of an existing deployment. RSNv3 is supported for new installations only, and the 4.13.0 release made random serial numbers the default for new installs. Record the exact package version from the target operating system repository and the release notes you are working from. Done means you have a written statement that the deployment is greenfield and the version is 4.13 or later. If any existing CA is in scope for migration, stop here and treat it as a separate project.
Decide the replica and clone plan
Before installation, the architecture team lists every server that will hold a CA, replica or clone, and states how each one will be created. A ranged clone made from an RSNv3 server fails, so any plan that depends on cloning from a ranged server, or on cloning an RSNv3 server into a ranged design, must be removed or redesigned. Confirm the replica layout against the project's deployment recommendations, including where PKI runs in each datacenter. Done means a signed-off topology diagram that names the creation method for every replica.
Confirm CA and KRA will use RSNv3
Random serial numbers must then be used by all PKI services, including the CA and the KRA, so the security owner confirms in writing that the KRA, if deployed, will follow the same serial mode as the CA. Mixed modes across PKI services are not a supported plan. Review the design page to confirm the current rules for each PKI component, and ask the platform vendor or FreeIPA project to confirm anything not stated there. Done means a one-line decision for the CA and for the KRA, both set to RSNv3, attached to the change record.
Install the first CA and record the serial mode
The engineer installs the first FreeIPA server with the integrated CA on the planned host, using the reviewed install options. Once the server is up, the engineer inspects the CA configuration and confirms that the serial number mode is random rather than ranged. Keep the output of the check in the build record, since it is the baseline every later replica will be compared against. Done means the CA reports random serial numbers and a test certificate issued by the CA carries a serial that does not follow a sequential range.
Verify the KRA serial mode
If the KRA is part of the deployment, the engineer checks its serial mode separately from the CA and compares it with the decision recorded in the earlier step. A KRA that does not match the CA breaks the requirement that all PKI services use RSNv3. Where the KRA is not installed, record that fact so the absence is deliberate rather than overlooked. Done means both PKI services are documented with their serial mode, and any mismatch has been resolved before further servers are added.
Build replicas with RSNv3-compatible methods
Each new replica is created using the method approved in the topology plan, and the engineer confirms that the method does not clone a ranged server into an RSNv3 topology or the reverse. Creation is performed one replica at a time, with the CA serial mode checked after each one. Keep the replica creation log and the serial mode output side by side. Done means every replica reports the same random serial mode as the first server and replication status shows no errors.
Record expired certificate pruning behavior
The 4.13.0 release notes state that expired certificates are removed automatically on new replicas after a 30-day retention period. The operations team confirms this behavior on the test topology and decides how expired certificate records fit into audit and retention requirements. Ask the vendor or project to confirm how pruning interacts with your own log retention policy before production. Done means a written note in the operations runbook describing the retention period, which systems prune, and who approves any change to that behavior.
How expired certificate pruning works on new replicas
FreeIPA 4.13.0 removes expired certificates automatically on new replicas after a 30-day retention period. The behavior is tied to the Dogtag CA data that a newly created replica receives, so the retention window starts from certificate expiry, not from the date the replica was built. For audit and troubleshooting, that means an expired certificate stays visible on a new replica for 30 days after it lapses, which is the window in which you can still answer questions about a service outage, a failed renewal or a certificate presented to a service. After that window, the record is gone from that replica, so any question about an older certificate has to be answered from somewhere else.
The retention rule does not tell you how existing replicas behave. The release note describes pruning on new replicas, and it does not, in the material available here, confirm that servers installed before 4.13.0 or upgraded in place prune in the same way. Confirm this with the FreeIPA release notes and a lab test on your exact version before you rely on it. Also confirm whether pruning touches the CA's own certificate records and the KRA, since the serial number design requires both to use random serials once RSNv3 is active.
Before any pruning takes effect, record what you would otherwise lose. Export the certificate inventory from ipa cert-find with expiry dates, subjects and serials, keep your ipa-backup archives for the period you need, and log which services hold each certificate through certmonger or your own tracking. Keep these records under the same retention rules your auditors expect for certificate lifecycle evidence. Then test the pruning behavior on a replica built from your current version and check that your records still answer the questions your security and compliance teams ask.
Security and operational considerations for RSNv3
Random serial numbers change how certificates are found, revoked and audited, so the operational work sits around the CA rather than in the switch itself. The cards below cover lookup and audit habits, revocation on the first server, backups before any CA change, consistency across CA and KRA, issuance monitoring and CA administration access.
Lookup and audit without sequential numbers
Many teams have scripts, tickets and audit queries that assume serial numbers rise over time or can be read as a sequence. With random 128-bit serials, lookups should key on the full serial, subject, issuer and fingerprint, and reports should not infer issuance order from the number. Check every internal tool that parses serials before you enable RSNv3 on a new installation, and confirm how your auditors expect certificate records to be sampled.
Revocation and CRL on the first server
By default the first server in a FreeIPA topology handles certificate renewal and CRL publication. Revocation requests and CRL generation therefore depend on that server being healthy, reachable and correctly configured. Before relying on RSNv3 for revocation, confirm which server publishes the CRL in your deployment, how clients and relying parties fetch it, and what your procedure is when that server is down.
Backups before any CA change
Take a full backup with the backup tooling before enabling RSNv3, changing CA configuration or upgrading across the release that makes random serials the default. Restoring an outdated backup into an active replica topology can break replication, so restore tests should run in an isolated copy, not in production. Record which backup corresponds to which CA state, and keep the backup and its key material under the same access controls as the live servers.
Consistency across CA and KRA
RSNv3 must be used by every PKI service in the deployment, including the CA and the KRA. A mixed setup with some services on ranged serials and others on random serials is not a supported state to assume is safe. Before you change serial behavior, inventory which PKI components run on each server, confirm that they all reach the same configuration, and treat any service that cannot follow the change as a blocker.
Monitoring issuance and expiry
Random serials do not make issuance easier to watch, so set up monitoring on the events you can trust: certificate requests, renewals, revocations, CRL publication and the count of active certificates by profile. Watch for unexpected spikes from enrolled hosts. Expired certificate pruning on new replicas uses a retention window, so confirm when your replicas remove expired records before you rely on them for historical evidence.
Access control over CA administration
Anyone who can change CA settings, issue certificates or access the CA signing material can affect every certificate the CA trusts. Limit CA administration to named roles, use separate accounts for administrators, and log each change to serial configuration. Review who holds these roles on a schedule and when staff change, and document who can authorize a restore that would rewrite CA state.
Questions teams ask about random serial numbers
Can an existing FreeIPA deployment switch to random serial numbers?
No, not by changing a setting. Random serial numbers (RSNv3) are supported for new installations only, so a deployment built with ranged serial numbers keeps them. The design requires every PKI service, including the CA and KRA, to use RSNv3 once it is enabled. Creating a ranged clone from an RSNv3 server also fails, which limits how you can copy or extend a topology built on it. Confirm the current behavior against the FreeIPA random serial numbers design before you plan any change.
What does a move to random serials actually require?
In practice it is a rebuild decision rather than a configuration change. The main steps are to confirm which servers hold the CA and KRA roles, decide whether the new CA will be a fresh installation, and plan how existing certificates, service certificates and replicas will be carried across. Expect to check that every PKI-dependent service and client still works after the change. Your team should document the target topology, the data you must keep, and the rollback path before any work starts.
Does random serial numbering change cost or effort?
It can, mainly because the work is a rebuild or migration instead of an upgrade. The cost drivers are the number of replicas, how many services depend on the CA, whether you use an HSM or externally signed CA, and how many certificates must be reissued or verified. Other drivers include the amount of custom integration and the test coverage you require. Ask any provider for a written scope that lists these items, the test cases, and what is excluded, so the quote reflects your environment.
How long does planning and validation take?
The duration depends mostly on topology. A single-site deployment with few services is simpler to plan and test than several datacenters with replicas, DNS roles and integrated clients. Validation time grows with the number of services that consume certificates and with the number of test environments you need before production. No fixed figure applies to every deployment, so ask for a timeline tied to your server count, sites and service inventory, and confirm which validation steps the timeline includes.
What does the work need from our team?
Plan for time from the people who own the CA, the directory, DNS and each service that uses certificates. They must confirm which certificates are in use, who can approve a change window, and how clients will receive new trust material. Your security or compliance lead should review the new serial and retention behavior against your internal policy. Also reserve staff for testing and for rollback decisions, since a broken PKI chain can affect logins, TLS and replication at the same time.
Can our own team do this without a partner?
Often yes, if your team already operates FreeIPA, has tested backups and restores, and has experience with the Dogtag CA. The risk comes from replication and CA state. Restoring an outdated backup into an active replica topology can break replication, and the first server handles certificate renewal and CRL publication by default. A partner can help by writing the plan, building a staging topology and running the validation. Whichever route you take, ask for a written scope and a clear list of deliverables before work starts.
What happens to expired certificates after the change?
Starting with FreeIPA 4.13.0, expired certificates are removed automatically on new replicas after a 30-day retention period, according to the FreeIPA 4.13.0 release notes. Teams should check how this pruning interacts with their audit, incident and recovery requirements before relying on it. If you need older expired certificates for evidence or troubleshooting, plan an export or archive step, and confirm with your compliance owner how long records must be kept.
How DeployOpen scopes FreeIPA certificate work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA deployments that issue certificates from the Dogtag CA. For random serial number work, we start by establishing whether your FreeIPA servers are eligible for RSNv3 and what that means for your replica and clone plans.
How we scope
- Confirm the installed FreeIPA version and whether the CA was created with ranged or random serial numbers before any change is proposed.
- Inventory replicas, ranged clones and any tooling that depends on the current serial number range.
- Agree in writing which servers, certificate profiles and expiry handling are in scope, under a fixed-scope engagement.
How we build
- Build a test FreeIPA topology that mirrors production, then run certificate issuance, renewal and replica creation against it.
- Verify that all PKI services, including the CA and KRA where deployed, follow the random serial number configuration you chose.
- Record each configuration step, command and rollback point so the change can be reviewed and repeated by your own team.
How we hand over
- Deliver a runbook covering serial number behavior, clone restrictions and the expired certificate pruning settings in your environment.
- Document the tests performed, their results and the open items your auditors or security team should review.
- Walk your engineers through monitoring of certificate renewal and CRL publication on the first server.
How we support
- Offer ongoing support and upgrade work under a retainer, covering FreeIPA 4.x releases and security fixes as they ship.
- Re-test certificate issuance and replica behavior after each upgrade or topology change.
- Confirm with your team, and with the vendor where needed, any capability or release detail before relying on it in production.
