Fix has been merged upstream: https://hg.mozilla.org/projects/nss/rev/db68b6975216

Moving to POST.

This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.

The Apache, 389-ds and KDC certs are renewed by proxying through IPA using the cert-request command. The CA subsystem certificates are renewed directly against the CA.

The error reported by certmonger is an SSL error coming out of curl and unfortunately it provides no details on the cause. It might help to try other tools to see if they provide additional details:

curl -v --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key -d "serialNumber=1&xml=true" https://`hostname`:8443/ca/agent/ca/displayBySerial

and

openssl s_client -host `hostname` -port 8443 -cert /var/lib/ipa/ra-agent.pem -key /var/lib/ipa/ra-agent.key

Once connected you'll need to type/paste this in:
POST /ca/agent/ca/displayBySerial HTTP/1.1
Host: <the IPA master hostname>
Content-Length: 23
Content-Type: application/x-www-form-urlencoded

serialNumber=1&xml=true

If they both succeed they'll return a big blob of cert output, the content of which is not important. These commands will exercise both the NSS and OpenSSL client libraries.

(In reply to Rob Crittenden from comment #41)
> The Apache, 389-ds and KDC certs are renewed by proxying through IPA using
> the cert-request command. The CA subsystem certificates are renewed directly
> against the CA.
> 
> The error reported by certmonger is an SSL error coming out of curl and
> unfortunately it provides no details on the cause. It might help to try
> other tools to see if they provide additional details:
> 
> curl -v --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key -d
> "serialNumber=1&xml=true" https://`hostname`:8443/ca/agent/ca/displayBySerial
> 
> and
> 
> openssl s_client -host `hostname` -port 8443 -cert /var/lib/ipa/ra-agent.pem
> -key /var/lib/ipa/ra-agent.key

> If they both succeed they'll return a big blob of cert output, the content
> of which is not important. These commands will exercise both the NSS and
> OpenSSL client libraries.

note though that the s_client will NOT abort the connection if it cannot verify server certificate
one needs to look also for `Verify return code: 0 (ok)` in the s_client output

Filed a new bug for the new issue:

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1737910
Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1571677

Hubert, thank you, you are correct and let me explain:

I was using the vfychain program to perform verification.  An NSSDB contains the constrained
CA cert with trust 'CT,C,C', then I execute:

  [NSS_ENABLE_PKIX_VERIFY=1] /usr/lib64/nss/unsupported-tools/vfychain -d . -a ipara.pem

The problem was I was not supplying '-u 0' to indicate client usage.  Adding that flag, I
observe that the legacy verifier succeeds and libpkix verifier fails.

I will clarify this in mozbz:1571677.

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, 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/RHSA-2019:2237