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