On Thu, Oct 21, 2021 at 01:25:09PM -0500, Endi Dewata via FreeIPA-users wrote:
On Thu, Oct 21, 2021 at 12:44 PM Endi Dewata
<edewata(a)redhat.com> wrote:
> I think the class loading messages above were generated
> by Tomcat. That's probably how it resolves the classes, so
> I don't think that's an issue.
>
> Could you raise the debug level in the CA subsystem too?
>
https://github.com/dogtagpki/pki/wiki/Configuring-Subsystem-Debug-Log
> The authenticator uses the LDAP connection in the CA to
> find the user in DS, so there might be an issue there.
>
Actually it's a bit different for ACME. I just updated the above page.
Could you raise the logging level in ACME too?
I've increased all the loglevels to FINE, there are no additional logs:
INFO: PKIAuthenticator: Authenticate with client certificate
authentication
INFO: Authenticating certificate chain:
INFO: - CN=IPA RA,O=PIPEBREAKER.PL
INFO: - CN=Certificate Authority,O=PIPEBREAKER.PL
INFO: PKIAuthenticator: Result: false
and in ca/debug-<date>.log:
2021-10-22 19:55:32 [Timer-0] FINE: LdapBoundConnFactory: number of connections: 3
2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: Certificates:
2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: - CN=IPA RA,O=PIPEBREAKER.PL
2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: parent: CN=Certificate
Authority,O=PIPEBREAKER.PL
2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: - CN=Certificate
Authority,O=PIPEBREAKER.PL
2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: child: CN=IPA
RA,O=PIPEBREAKER.PL
dirsrv log shows 1 certificate is being found:
[22/Oct/2021:20:05:35.119328765 +0200] conn=4469 op=9 SRCH
base="ou=people,o=ipaca" scope=1 filter="(description=2;105;CN=Certificate
Authority,O=PIPEBREAKER.PL;CN=IP
A RA,O=PIPEBREAKER.PL)" attrs=ALL
[22/Oct/2021:20:05:35.119963856 +0200] conn=4469 op=9 RESULT err=0 tag=101 nentries=1
wtime=0.000231485 optime=0.000638726 etime=0.000867770
[22/Oct/2021:20:05:35.277708077 +0200] conn=4508 op=3 UNBIND
BUT in acme/debug.log:
2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] FINE: Looking up certificates
2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: Authenticating user with client
certificate
2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: Finding user by cert:
2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: - base DN: ou=people,o=ipaca
2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: - filter:
description=2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O=PIPEBREAKER.PL
2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: User: uid=ipara,ou=people,o=ipaca
2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] FINE: Realm.authenticate() returned
false
So a problem with realm?
This look to be configured, but I found a possible discrepancy in "password":
$ cat /etc/pki/pki-tomcat/acme/realm.conf
# VERSION 2 - DO NOT REMOVE THIS LINE
authType=BasicAuth
class=org.dogtagpki.acme.realm.DSRealm
groupsDN=ou=groups,o=ipaca
usersDN=ou=people,o=ipaca
url=ldaps://kaitain.pipebreaker.pl:636
configFile=/etc/pki/pki-tomcat/ca/CS.cfg
username=acme-kaitain.pipebreaker.pl
password=<40-character long text string>
While userPassword:: field of uid=acme-kaitain.pipebreaker.pl,ou=people,o=ipaca
contains very long base64 string, which decodes to 447 string starting
with {PBKDF2_SHA256}. How to make sure it's corresponds to the same
value?
--
Tomasz Torcz Once you've read the dictionary,
@ttorcz:pipebreaker.pl every other book is just a remix.