Next Range Calculation error #4840
Conversation
… to Dec BigInteger to add increment correctly
|
|
@parrjd I have tried to reproduce the next range calculation problem this PR tries to fix. I have created 9 certificate to get to the new range and in the DS I have: and Therefore, the The log information just after the change is also reported correctly: The only place where I found a problem is in the The serial number end range is in hex format but the request end range is in decimal so the problem is specific to the serial number. If you have different result could describe how to configure the CA to get the same behaviour? |
you need to use a larger increment then 10 anything above 10 will produce the error 11 Hex is 17 Dec. With an increment of 11 your first next range would be 9 - 26 since it is adding a converted 11 hex to 9, and what is stored in the CS,cfg would be 1A causing a Gab from 1A - 27 serials in hex and the next being |
I have tested with range of size 12 (for both certificates and requests) and next range is in decimal in the DS entry however the range is wrong because the increment is read as hex from the CS.cfg so I have increments of 12 for the requests and 18 (0x12 ) for the certificate: There is a problem of conversion but I do not think this PR is fixing the right place. I'll do additional investigation to verify. |
|
@fmarco76 pki/base/server/src/main/java/com/netscape/cmscore/dbs/Repository.java Lines 425 to 496 in e984ab7 The Value stored in the Database in the PROP_NEXT_RANGE attribute should be in HEX as it matches the beginning of the Next Range values stored in the CS.cfg I have seen both the values in the DB and the values in CS.cfg being Hex with letters a-f in the value Calculation for mNextMax Serial number uses mRadix pki/base/server/src/main/java/com/netscape/cmscore/dbs/Repository.java Lines 693 to 695 in e984ab7 Where as the Calculation for what is stored in the database does not. pki/base/server/src/main/java/com/netscape/cmscore/dbs/Repository.java Lines 541 to 545 in e984ab7 Based on this section of code it looks like ReplicaID and requests are treated as base 10 (dec), and SerialNo are treated as base 16 (hex) |
|
@parrjd Yes, you are correct. Actually, internal operations are on BigInteger so it does not matter but serial and keys (in KRA subsystem) use mRadix to reead/write from CS.cfg. Differently, the SubsystemRangeUpdateCLI read from CS.cfg in decimal for all the ranges and write them in DS, this is the reason the initial nextRange match the value written in CS.cfg. This PR could solve some of the error but there are several limitation I am investigate. In the documentation I did not find what format the ranges should have. I would investigate with other if it is possible to use the same format for both. This is trivial for new instance but for running instances with ranges created this is problematic, I have problem updating the value to be all hex or all decimal but I am working on that. |
|
What we have done as an interim break fix to keep it from leaving large gaps is we are watching for a role and when it roles, we are pulling the values from the DS Range entry and comparing it to the CS.cfg and if the end does not match the DS Range entry we are updating the CS.cfg to match and then restarting the CA instance. 13, certificateRepository, ranges, ca.pki.example.comdn: cn=13,ou=certificateRepository,ou=ranges,dc=ca,dc=pki,dc=example,dc=com dbs.beginSerialNumber=13 So we are updating dbs.endSerialNumber= to match the endRange: value from the DS instance |
NextRange is stored in ldap database as a Hex string
mIncrementNo is provided by CertificateRepository.java and is converted dec to BigInt with mRadix
nextRangeNo Needs to be treated the same as mIncrementNo so that add and subtract work correctly and produce the correct values and match up with what will be put into CS.cfg to prevent large gaps with sequential Serial Managment.