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@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?
ACME also has a realm configuration: https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Configur... https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Configur... so there could be an issue there.
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?