Description of problem: NextRange is pulled from the DS as a HEX, and Serial Increment is converted from Hex to Dec causing a calculation error resulting in what is written to the DS not matching what is written to the CS.cfg for the next range, and when rollover occurs for the begin and end of the new range. How reproducible: Create a CA with small range and instantiate certificate to fill the range. After few renewal some gaps are created between ranges. Steps to Reproduce: Following upstream test: https://github.com/dogtagpki/pki/blob/master/.github/workflows/ca-ssnv1-test.yml 1. Create a CA with the follwoing parameter: # pkispawn -f /usr/share/pki/server/examples/installation/ca.cfg \ -s CA \ -D pki_ds_url=ldap://ds.example.com:3389 \ -D pki_request_id_generator=legacy \ -D pki_request_number_range_start=1 \ -D pki_request_number_range_end=10 \ -D pki_request_number_range_increment=10 \ -D pki_request_number_range_minimum=5 \ -D pki_request_number_range_transfer=5 \ -D pki_cert_id_generator=legacy \ -D pki_serial_number_range_start=9 \ -D pki_serial_number_range_end=18 \ -D pki_serial_number_range_increment=12 \ -D pki_serial_number_range_minimum=9 \ -D pki_serial_number_range_transfer=9 \ -v 2. Enable the serial management: # pki-server ca-config-set dbs.enableSerialManagement true 3. Enroll certificate to fill the entire range multiple time 4. Check the list of serial released. A similar problem is present when clones are created. The range of the cloned CA and the one of the master CA could be not consecutive. Actual results: Certificate ids list show missing number, E.g. with above configuration there is a gap between 0x2a and 0x37. Expected results: Serial should be consecutive. Additional info:
Fixed implementing a new serial generator, SSNv2 documented here: https://github.com/dogtagpki/pki/wiki/Sequential-Serial-Numbers-v2 Migration from current serial id to the new SSNv2: https://github.com/dogtagpki/pki/wiki/Migrating-to-Sequential-Serial-Numbers-v2
Fixed in: commit 475b58c996abc1999376684b60ef160955930544 Author: Marco Fargetta <mfargett> Date: Thu Nov 14 18:10:18 2024 +0100 Fix range update to legacy2 with clone When a new clone is deployed it get the initial allocation from the current range or the next range already allocated. The code was not considering the case of next range so it could generate a range overlap. The fix will check if the next range is totally allocate for the service or it is partial and in this case only the remaining part is used.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (CA bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2025:3401
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days