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?
> ACME also has a realm configuration:
>
https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi...
>
https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi...
> 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?
This is the password for the username in the file. It is basically
unused by IPA as IPA uses client auth with the RA agent certificate.
rob