On Thu, Nov 04, 2021 at 08:45:17PM -0500, Endi Dewata via
FreeIPA-users wrote:
>
> I added some log messages into this file if you want to try again:
>
https://github.com/edewata/pki/blob/debug-v10.10/base/acme/src/main/java/...
>
> The build is available from this repo:
>
https://copr.fedorainfracloud.org/coprs/edewata/pki-10.10/builds/
Thanks… For most problems, the root cause is almost always DNS.
For IPA, it's almost always certificate ;)
Verbose builds produced following logs:
2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: LDAP search:
2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: - base DN: ou=people,o=ipaca
2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: - filter:
(description=2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O=PIPEBREAKER.PL)
2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: User:
uid=ipara,ou=people,o=ipaca
2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: Validating cert data in
uid=ipara,ou=people,o=ipaca
2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] WARNING: User
uid=ipara,ou=people,o=ipaca has no certificates
Impossible! I triple checked that. Let check again and compare with fresh install:
% ldapsearch -h kaitain.pipebreaker.pl -D cn=directory\ manager -W -o ldif-wrap=no \
-b uid=ipara,ou=people,o=ipaca
[…]
dn: uid=ipara,ou=people,o=ipaca
description: 2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O=PIPEBREAKER.PL
userCertificate;binary:: MIIDajCCAlKgAw…
[…]
While fresh install gives:
dn: uid=ipara,ou=people,o=ipaca
description: 2;7;CN=Certificate Authority,O=IPADEV.PIPEBREAKER.PL;CN=IPA
RA,O=IPADEV.PIPEBREAKER.PL
userCertificate:: MIID/zCCAmegAwIBA…
There's an additional ";binary" in certificate attribute on my prod
server. And I was comparing
only base64 encoded part.
And that was it. After removing ';binary' from attribute name,
`pki-acme-manage` can authenticate.
Thank you very much for patience and assistance!
It is always a certificate.
That is quite unexpected as the same entry worked in other areas of
dogtag. I'm not sure if I can detect this in ipa-healthcheck but I'll
take a look. According to
they
should be treated equivalently within the LDAP server since it isn't
technically a subtype.
Endi, thanks for improving the logging! I hope that can be incorporated
into a future build.
rob