Patch has been merged to 389-ds-base upstream master (70bdd335d151e58e227fc2263ece9aedc0803152). Moving to POST.
could you please provide a specific certmap configuration that triggers the failure? I tried your example from the description, but it works on the older build without your fix.
I was able to reproduce by running:
ipa-server-install --subject-base "O=Acme\, Inc.,ST=Massachusetts,C=US"
which resulted in the following certmap.conf contents:
certmap default default
#default:FilterComps e, uid
#default:InitFn <Init function's name>
certmap ipaca CN=Certificate Authority,O=Acme\, Inc.,ST=Massachusetts,C=US
And the CA certificate:
Looking at the old version where Viktor ran the successful test I wonder if the testcase may not run into your fix (ldapu_issuer_certinfo)
The certmap_listinfo was defined but empty, so ldapu_issuer_certinfo failed to retrieve a certmap for the issuer and ldapu_cert_to_ldap_entry fall back to a default_certmap_info.
This fallback looks to be good enough to make the testcase successful.
Note, I am not familiar with that part of code and this update may make no sense.
So you really need a CA with a Subject DN that will cause problems, e.g. one with a comma in
one of the attribute values. There are other ways to trigger a failure but this is the best way.
The bug was due to (sometimes) incorrect parsing of the DN in the certmap file and
(always) incorrect comparison of DNs (i.e. it performed strncmp instead of a proper
DN comparison subroutine). So to trigger the issue you need a CA certificate with
a subject DN such that the comparison with the DN from the certmap file fails.
Of course if it falls back to the default certmap and the default certmap will work, then
there will not be an authentication failure.
I recommend to test this via IPA, using my instructions above, because that sets everything
up "just right" to trigger the bug (for affected version) and verify the fixed version.
To clarify further, with the affected version, ipa-server-install will fail during CA setup
(one of the later steps, when it imports certificate profiles).
Hope that helps!
See the description of https://pagure.io/freeipa/issue/7347 for a transcript of
what you would see when running ipa-server-install with an affected version of
389, using a subject base DN that would trigger the issue.
I'm using the following command:
# ipa-server-install -a password -p password -r EXAMPLE.COM --subject-base "O=Acme\, Inc.,ST=Massachusetts,C=US" -U
And it fails with:
[24/28]: migrating certificate profiles to LDAP
[error] RemoteRetrieveError: Failed to authenticate to CA REST API
Failed to authenticate to CA REST API
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
with various versions of ipa-server, pki-base and 389-ds-base on RHEL 7, RHEL 8 and Fedora 29.
The issue you mentioned is still open, and it mentions that the fix should be in multiple components. Is it fixed in every affected component?
Victor, that is the expected failure when 389DS does not include the fix. Could you please give exact package
versions you encountered this with?
The FreeIPA issue is still open because there is one related certmonger bug, but that bug does not affect
installation, only certificate renewal.
Victor, thanks for the details. Something, somewhere has regressed. Not sure yet if it's DS
or some other component. I'm looking into it.
(In reply to Fraser Tweedale from comment #11)
> Victor, thanks for the details. Something, somewhere has regressed. Not
> sure yet if it's DS
> or some other component. I'm looking into it.
Well the fix was not correctly applied in rhel 7.6.z, but this was just recently fixed in 389-ds-base-22.214.171.124-23. But upstream and in RHEL 8 it should be there as the PR was merged upstream.
After preliminary investigation, it seems the regression is in Dogtag or possibly FreeIPA,
not 389. But it is holding up the testing so feel free to fail QA, or just shelve the testing
for now, until the other issue is fixed.
Quick update: the certmonger issue that I thought was only a problem on renewal, is
a problem during installation as well. Anyhow I'll find a procedure for verifying
this DS fix indepdently of FreeIPA, and add steps here (tomorrow, most likely).
Thank you Fraser for the investigation!
If you can provide steps to reproduce outside of IPA context, that would great, since we can include this in our regression test suite.
In the meantime I did a build of certmonger with a patch from https://pagure.io/certmonger/pull-request/108 and verified that with this fix IPA server installation completes.
Marking as VERIFIED.
Viktor, very nice! Thank you for taking the initiative. I put a TODO on my list to develop
the repro steps outside of IPA. It is far from my highest priority but neither will I
forget about it :)
P.S. I keep writing your name "Victor". My apologies!