Patch has been merged to 389-ds-base upstream master (70bdd335d151e58e227fc2263ece9aedc0803152).  Moving to POST.

Hi Fraser,

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.

Thanks!

Victor,

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:DNComps
  #default:FilterComps    e, uid
  #default:verifycert     on
  #default:CmapLdapAttr   certSubjectDN
  #default:library        <path_to_shared_lib_or_dll>
  #default:InitFn         <Init function's name>
  default:DNComps
  default:FilterComps     uid
  certmap ipaca           CN=Certificate Authority,O=Acme\, Inc.,ST=Massachusetts,C=US
  ipaca:CmapLdapAttr      seeAlso
  ipaca:verifycert        on

And the CA certificate:

-----BEGIN CERTIFICATE-----
MIID0TCCArmgAwIBAgIBATANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJVUzEW
MBQGA1UECAwNTWFzc2FjaHVzZXR0czETMBEGA1UECgwKQWNtZSwgSW5jLjEeMBwG
A1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE5MDIwNTAzMTIzNFoXDTM5
MDIwNTAzMTIzNFowWjELMAkGA1UEBhMCVVMxFjAUBgNVBAgMDU1hc3NhY2h1c2V0
dHMxEzARBgNVBAoMCkFjbWUsIEluYy4xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1
dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAME+0kzeOMvk
JOqWAAi/oXv810bppKDgDe7lkhWaZCLfB1YOupkD88xveqHJtI4dA1ZHhzLv70N5
vJVMlSsLND+W3PLM44X8QTErYHSfaNprlknilQM6XK1DdXghqP1zk5tLkKyrGzY/
9h+oav/ZxUoDnzB8K0o1ngzBRqPmqPMi3rXhvzm2SOSnpYzJDV3ipT03VstIe2zO
qamefACCm3+2z0P5UaZWKqjjwTBfVMW9U+2mBKbTiAloNCr17M7ANGBv6mDxPRqU
3laY/5WUUolV4JwFb9uQ/SokT4Ube8E6erWfT+PEfW0tKjhk/V6aml7l+NABVOg4
O88RV2Jr/p0CAwEAAaOBoTCBnjAfBgNVHSMEGDAWgBTWkZnwtiAdy/93Q1B4O/YO
VZV1TTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQU
1pGZ8LYgHcv/d0NQeDv2DlWVdU0wOwYIKwYBBQUHAQEELzAtMCsGCCsGAQUFBzAB
hh9odHRwOi8vaXBhLWNhLmlwYS5sb2NhbC9jYS9vY3NwMA0GCSqGSIb3DQEBCwUA
A4IBAQA2Ui+k21j9EqhBQX8j/XtAm6LEu+PMyN1t39dcwG32EOacecu/i7LhEmv+
QMlunPAa2SvkmbraVKl7SKxiRwtnHDzOX/jrBXFd+UBihI0d9dErZsBF1qUDyKP/
g0GKfRdhw+JC36w4uDbIG0iTeUTYhn6QBGi1jAnui6k3G8feiAZPISxSCSjAhRXJ
ZQTMmJ6Q0hLk4ygbwcmrYA1idXxsfO9AR9Kxnn+URnXhJzNbBmKvpD7L5Wu0c1hx
0WiLHEzeoAb6p/R8jdG4jWZ9DRYWruj/b5sEZb5QK77cZ5Tl3lwRA5l3aJhy17oT
tc95ePG6IZkXqorjMJmVoOYQH6SU
-----END CERTIFICATE-----

HTH,
Fraser

Hi Fraser,

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.

Fraser,

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?

Thanks!

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.

On RHEL8
ipa-server-4.7.1-10.module+el8+2699+aa606a46.x86_64
pki-base-10.6.9-1.module+el8+2694+429d2b2b.noarch
389-ds-base-1.4.0.20-7.module+el8+2750+1f4079fb.x86_64
certmonger-0.79.6-5.el8

On Fedora29:
freeipa-server-4.7.2-1.fc29.x86_64
pki-base-10.6.9-1.fc29.noarch
389-ds-base-1.4.0.21-1.fc29.x86_64
certmonger-0.79.6-3.fc29.x86_64

On Fedora30:
freeipa-server-4.7.2-1.fc30.x86_64
pki-base-10.6.9-1.fc30.noarch
389-ds-base-1.4.1.1-1.fc30.1.x86_64
certmonger-0.79.6-4.fc30.x86_64

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-1.3.8.4-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.

Builds tested:
ipa-server-4.7.1-10.module+el8+2699+aa606a46.x86_64
pki-base-10.6.9-2.module+el8+2728+a4ad6bba.noarch
389-ds-base-1.4.0.20-7.module+el8+2750+1f4079fb.x86_64
certmonger-0.79.6-5.bz1653165.el8.x86_64

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!