Bug 1641804
| Summary: | [RFE] Random Serial Number v3 Support | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Rob Crittenden <rcritten> | |
| Component: | pki-core | Assignee: | Endi Sukma Dewata <edewata> | |
| Status: | CLOSED ERRATA | QA Contact: | PKI QE <bugzilla-pkiqe> | |
| Severity: | high | Docs Contact: | Florian Delehaye <fdelehay> | |
| Priority: | urgent | |||
| Version: | 9.1 | CC: | aakkiang, ckelley, dconsoli, edewata, ftweedal, jvilicic, mharmsen, pcech, radrao, skhandel | |
| Target Milestone: | rc | Keywords: | FutureFeature, Reopened, Triaged | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | pki-core-11.2.0-0.2.beta1.el9 | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2184509 (view as bug list) | Environment: | ||
| Last Closed: | 2022-11-15 10:13:02 UTC | Type: | Feature Request | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1851495, 2075154 | |||
| Bug Blocks: | 747959, 2184509 | |||
|
Description
Rob Crittenden
2018-10-22 20:08:40 UTC
Unlike the entries under ou=certificateRepository, the CN of a request is
not related to the serial number of the issued cert.
Request objects have a 'serialno' attribute. I will check whether that
is the serial number of the issued cert, which could be used for lookup
instead.
Alternatively, look up the certificate first, and the certificate entry
contains a reference to the request that produced it, e.g.:
% ldapsearch -LLL -D cn=directory\ manager -w4me2Test
-b ou=certificateRepository,ou=ca,o=ipaca '(cn=1)' metaInfo
dn: cn=1,ou=certificateRepository,ou=ca,o=ipaca
metaInfo: profileId:caCACert
metaInfo: requestId:1 <-- this tells you the request ID.
This does not match the behavior seen elsewhere. When re-issuing a cert certmonger renews by serial number: GET /ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=5&renewal=true&xml=true&requestor_name=IPA The returned certificate from dogtag was for a different hostname altogether. The hostname matched the value for extdata-req--005fsubject--005fname in: dn: cn=5,ou=ca,ou=requests,o=ipaca We had to manually reconfigure certmonger to not do renewal by serial number to work around this. This was not a one-off. So I'm ok with changing the query but it doesn't match what we were seeing in production. Thanks for the extra info. I can't explain this and will need to investigate further. The problem might arise due to conflicting request and/or cert serialNo ranges on different replicas. Certainly the request ID should always be looked up via the cert record. The renewal code should not be using the serialNo as the request ID. I will confirm that this is not the case. Rob, next time you see a case like this (renewed cert has different serial number) please loop me in. We will need to investigate whether there are range conflicts and/or replication conflicts. Will do. I'll see if the logs provided by users who have tried the tool any additional information. Further info: The ProfileSubmitServlet reads the "serial_num" param and sets it into the CertEnrolmentRequest data, before invoking the RenewalProcessor: https://github.com/dogtagpki/pki/blob/v10.6.7/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileSubmitServlet.java#L269-L274 In RenewalProcessor the serial numbers gets read of the data: https://github.com/dogtagpki/pki/blob/v10.6.7/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java#L113-L117 and used to look up the certificate record: https://github.com/dogtagpki/pki/blob/v10.6.7/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java#L181 The certificate record is then used to look up the original request: https://github.com/dogtagpki/pki/blob/v10.6.7/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java#L208 In the implementation of getOriginalRequest we see that the request ID is read from the corresponding metaInfo field: https://github.com/dogtagpki/pki/blob/v10.6.7/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java#L231-L248 Rob, I therefore suspicion that there is more to the story with the cases we have seen (e.g. conflict request ranges). The fact that the serial number in question is so low (5) strengthens the suspicion. In any case you should update the checker query to look up the request record via the certificate record. As per grooming meeting 20200428, this bug can be fixed by having a upgrade to database framework RSNv3 has been implemented in master branch (PKI 11.2): * https://github.com/dogtagpki/pki/blob/master/docs/installation/ca/Installing-CA-with-Random-Serial-Numbers-v3.adoc * https://github.com/dogtagpki/pki/blob/master/docs/installation/kra/Installing-KRA-with-Random-Serial-Numbers-v3.adoc Design doc: * https://github.com/dogtagpki/pki/wiki/Random-Certificate-Serial-Numbers-v3 Installation docs: * https://github.com/dogtagpki/pki/blob/master/docs/installation/ca/Installing-CA-with-Random-Serial-Numbers-v3.adoc * https://github.com/dogtagpki/pki/blob/master/docs/installation/kra/Installing-KRA-with-Random-Serial-Numbers-v3.adoc Configuration/migration docs: * https://github.com/dogtagpki/pki/wiki/Configuring-CA-with-Random-Serial-Numbers-v3 * https://github.com/dogtagpki/pki/wiki/Configuring-KRA-with-Random-Serial-Numbers-v3 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 (pki-core 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/RHEA-2022:8053 |