$ ipa-acme-manage enable Failed to authenticate to CA REST API The ipa-acme-manage command failed.

Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem. This is the same certificate; serial number matches, too.

What should I do next to resolve this authentication issue?

Tomasz Torcz via FreeIPA-users wrote: > On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-users wrote: >> $ ipa-acme-manage enable >> Failed to authenticate to CA REST API >> The ipa-acme-manage command failed. >> > >> Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem. >> This is the same certificate; serial number matches, too. > >> What should I do next to resolve this authentication issue? > > No ideas how to proceed? > Most troubleshooting guides end at comparing certs on the filesystem and > in LDAP. What's the next step? > I'd suggest trying ipa-healthcheck. It does these comparisons and more.

Does the RA cert work in other contexts? Does ipa cert-find work? Can you request a test certificate?

Tomasz Torcz via FreeIPA-users wrote: > On Tue, Oct 12, 2021 at 02:33:01PM -0400, Rob Crittenden via FreeIPA-users wrote: >> Tomasz Torcz via FreeIPA-users wrote: >>> On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-users wrote: >>>> $ ipa-acme-manage enable >>>> Failed to authenticate to CA REST API >>>> The ipa-acme-manage command failed. >>> >>> No ideas how to proceed? >>> Most troubleshooting guides end at comparing certs on the filesystem and >>> in LDAP. What's the next step? > So this shows that the RA certificate is fine. It looks like a group permission issue within the CA that the RA is not allowed to perform ACME actions. Some things to check:

- uid=acme-<IPA SERVER HOSTNAME>,ou=people,o=ipaca and uid=ipara,ou=People,o=ipaca are both uniqueMember attributes of cn=Enterprise ACME Administrators,ou=groups,o=ipaca

- the entry id=acme-<IPA SERVER HOSTNAME>,ou=people,o=ipaca exists

- In cn=aclResources,o=ipaca there is the value: resourceACLS: certServer.ca.certs:execute:allow (execute) group="Enterprise ACME Administrators":ACME Agents may execute cert operations

Tomasz Torcz via FreeIPA-users wrote: > On Fri, Oct 15, 2021 at 02:04:42PM -0400, Rob Crittenden via FreeIPA-users wrote: >> Tomasz Torcz via FreeIPA-users wrote: >>> On Tue, Oct 12, 2021 at 02:33:01PM -0400, Rob Crittenden via FreeIPA-users wrote: >>>> Tomasz Torcz via FreeIPA-users wrote: >>>>> On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-users wrote: >>>>>> $ ipa-acme-manage enable >>>>>> Failed to authenticate to CA REST API >>>>>> The ipa-acme-manage command failed. >>>>> >>>>> No ideas how to proceed? >>>>> Most troubleshooting guides end at comparing certs on the filesystem and >>>>> in LDAP. What's the next step? >>> >> >> So this shows that the RA certificate is fine. It looks like a group >> permission issue within the CA that the RA is not allowed to perform >> ACME actions. >> >> Some things to check: >> > > All below seem to be correct: > >> - uid=acme-<IPA SERVER HOSTNAME>,ou=people,o=ipaca and >> uid=ipara,ou=People,o=ipaca are both uniqueMember attributes of >> cn=Enterprise ACME Administrators,ou=groups,o=ipaca > > # base <cn=Enterprise ACME Administrators,ou=groups,o=ipaca> with scope > # subtree > # filter: (objectclass=*) > # requesting: uniqueMember > # > > # Enterprise ACME Administrators, groups, ipaca > dn: cn=Enterprise ACME Administrators,ou=groups,o=ipaca > uniqueMember: uid=acme-kaitain.pipebreaker.pl,ou=people,o=ipaca > uniqueMember: uid=ipara,ou=people,o=ipaca > uniqueMember: uid=acme-okda.pipebreaker.pl,ou=people,o=ipaca > > > >> - the entry id=acme-<IPA SERVER HOSTNAME>,ou=people,o=ipaca exists > > There is no entry with id=, but there is one with uid= (I assume you > made a typo): > > # acme-kaitain.pipebreaker.pl, people, ipaca > dn: uid=acme-kaitain.pipebreaker.pl,ou=people,o=ipaca > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: cmsuser > uid: acme-kaitain.pipebreaker.pl > cn: acme-kaitain.pipebreaker.pl > sn: acme-kaitain.pipebreaker.pl > usertype: agentType > userstate: 1 > userPassword:: … > > >> - In cn=aclResources,o=ipaca there is the value: >> resourceACLS: certServer.ca.certs:execute:allow (execute) >> group="Enterprise ACME Administrators":ACME Agents may execute cert >> operations > > $ ldapsrch -b cn=aclResources,o=ipaca resourceACLs | grep ACME > Enter LDAP Password: > resourceACLs: certServer.ca.certs:execute:allow (execute) group="Enterprise ACME Administrators":ACME Agents may execute cert operations > > So everything looks to be in order. > Maybe there is a way to increase logging in com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate PKIAuthenticator ? > I don't know. Endi, what would you suggest here? thanks rob

On Wed, Oct 20, 2021 at 08:40:30PM -0500, Endi Dewata via FreeIPA-users wrote: > Hi, > > I think error 401 means that the client cert could not be mapped > to the user in DS. > > Could you check the uid=ipara,ou=people,o=ipaca to make sure > that the userCertificate and the description attributes contain the > right certificate? That was the first thing I've checked. userCertificate:: (after base64 decoding) is the same as /var/lib/ipa/ra-agent.pem - the same description, fingerprint, etc. openssl x509 -serial return "69" for both, and LDAP contains: description: 2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O= PIPEBREAKER.PL 105 (dec) == 69 (hex) so this is correct, too. > > You can also try setting the log level to INFO or FINE to see the > authentication process on the server side: > https://github.com/dogtagpki/pki/wiki/Configuring-Server-Logging This is something! There are new lines between starting certificate authentication and returning failure. First I thought there are libraries missing, but in the end all finish with "Loading class from parent": FINE: Calling authenticate() 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 FINE: loadClass(org.mozilla.jss.netscape.security.util.Cert, false) FINE: Searching local repositories FINE: findClass(org.mozilla.jss.netscape.security.util.Cert) FINE: --> Returning ClassNotFoundException FINE: Delegating to parent classloader at end: java.net.URLClassLoader@5fcfe4b2 FINE: Loading class from parent FINE: loadClass(netscape.ldap.LDAPSearchResults, false) FINE: Searching local repositories FINE: findClass(netscape.ldap.LDAPSearchResults) FINE: --> Returning ClassNotFoundException FINE: Delegating to parent classloader at end: java.net.URLClassLoader@5fcfe4b2 FINE: Loading class from parent FINE: loadClass(netscape.ldap.LDAPEntry, false) FINE: Searching local repositories FINE: findClass(netscape.ldap.LDAPEntry) FINE: --> Returning ClassNotFoundException FINE: Delegating to parent classloader at end: java.net.URLClassLoader@5fcfe4b2 FINE: Loading class from parent FINE: loadClass(com.netscape.cmscore.usrgrp.User, false) FINE: Searching local repositories FINE: findClass(com.netscape.cmscore.usrgrp.User) FINE: Loading class from local repository FINE: loadClass(netscape.ldap.LDAPAttribute, false) FINE: Searching local repositories FINE: findClass(netscape.ldap.LDAPAttribute) FINE: --> Returning ClassNotFoundException FINE: Delegating to parent classloader at end: java.net.URLClassLoader@5fcfe4b2 FINE: Loading class from parent INFO: PKIAuthenticator: Result: false FINE: Failed authenticate() test Second invocation of "pki-acme-manage status" do not generate those class messages: FINE: Calling hasUserDataPermission() FINE: User data constraint already satisfied FINE: Calling authenticate() 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 FINE: Failed authenticate() test FINE: JSSEngine: wrap(ssl_fd=org.mozilla.jss.nss.SSLFDProxy[1522605810@00079ea974550000])

On Thu, Oct 21, 2021 at 12:44 PM Endi Dewata <edewata(a)redhat.com&gt; 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?

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.

Tomasz Torcz via FreeIPA-users wrote: >> 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

On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org&gt; wrote: > Tomasz Torcz via FreeIPA-users wrote: > >> 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. > > But IIRC in IPA case it's configured to reuse the internaldb connection defined in CS.cfg so these params don't need to be specified again. Is there a working IPA instance with ACME that can be compared against?

Tomasz Torcz via FreeIPA-users wrote: > On Mon, Oct 25, 2021 at 10:09:56AM -0500, Endi Dewata via FreeIPA-users wrote: >> On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < >> freeipa-users(a)lists.fedorahosted.org&gt; wrote: >> >>> Tomasz Torcz via FreeIPA-users wrote: >>>>> 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. >>>> >> >> But IIRC in IPA case it's configured to reuse the internaldb connection >> defined in CS.cfg so these params don't need to be specified again. >> Is there a working IPA instance with ACME that can be compared >> against? > > So I did a clean install of Fedora 34 and FreeIPA. Clean install works > as expected. I did comparison between fresh and mine install, > there were discrepancies I mostly fixed, but it didn't change my > problem. > Failure looks like that in logs (pki-tomcat/acme/debug-<data>.log): > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: Finding user by cert: > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - base DN: ou=people,o=ipaca > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - filter: description=2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O= PIPEBREAKER.PL > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: User: uid=ipara,ou=people,o=ipaca > 2021-11-03 18:43:08 [https-jsse-nio-8443-exec-12] FINE: Realm.authenticate() returned false Yeah, I noticed this in your logs as well. I have no insight into what PKI does to authenticate beyond the things you've already checked. We know that this cert is ok because you can authenticate to the CA using it in other ways. It would be nice if they logged some reason for the failure to authenticate but I'm not sure how to get that. rob > > > While on _fresh install_ correct log looks like: > > 2021-10-31 13:51:47 [https-jsse-nio-8443-exec-13] INFO: Authenticating user with client certificate > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Finding user by cert: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: ou=people,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: description=2;7;CN=Certificate Authority,O=IPADEV.PIPEBREAKER.PL;CN=IPA RA,O=IPADEV.PIPEBREAKER.PL > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: User: uid=ipara,ou=people,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Getting user roles: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: ou=groups,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: uniqueMember=uid=ipara,ou=people,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Roles: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=Certificate Manager Agents,ou=groups,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=Registration Manager Agents,ou=groups,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=Enterprise ACME Administrators,ou=groups,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Initializing ACMEApplication > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: Session: 3DBCD2FB21ADFDD04ADC518C97AA07B4 > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: Principal: GenericPrincipal[ipara(Certificate Manager Agents,Enterprise ACME Administrators,Registration Manager Agents,)] > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: Principal: ipara > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: Roles: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: - Certificate Manager Agents > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: - Enterprise ACME Administrators > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: - Registration Manager Agents > 2021-10-31 13:51:48 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: LDAP: search ou=config,ou=acme,o=ipaca > 2021-10-31 13:51:49 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: ACMERequestFilter: ACME service is disabled > > > Things I've observed on fresh install, which I've implemented on my production > (it changed nothing, provided here for documentation only): > > # in /etc/pki/pki-tomcat/ca/CS.cfg: > - added lines: > features.authority.description=Lightweight CAs > features.authority.enabled=true > features.authority.version=1.0 > > - 36 profile.* lines were missing; carefully added them, for example: > profile.AdminCert.class_id=caEnrollImpl > profile.AdminCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/AdminCert.cfg > > - also copied a long line starting with profile.listprofile.list= > > - /var/lib/pki/pki-tomcat/ca/profiles/ca on prod server contained 74 files, while > fresh install had over 90. I've copied missing ones from /usr/share/pki/ca/profiles/ca/ > > # in LDAP > - ipaca / groups / Certificate Manager Agents had entry for pkidbuser; added on prod > uniqueMember: uid=pkidbuser,ou=People,o=ipaca > - pkidbuser had 3 userCertificate: entries, two of them were expired; removed those

Tomasz Torcz via FreeIPA-users wrote: > On Mon, Oct 25, 2021 at 10:09:56AM -0500, Endi Dewata via FreeIPA-users wrote: >> On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < >> freeipa-users(a)lists.fedorahosted.org&gt; wrote: >> >>> Tomasz Torcz via FreeIPA-users wrote: >>>>> 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. >>>> >> >> But IIRC in IPA case it's configured to reuse the internaldb connection >> defined in CS.cfg so these params don't need to be specified again. >> Is there a working IPA instance with ACME that can be compared >> against? > > So I did a clean install of Fedora 34 and FreeIPA. Clean install works > as expected. I did comparison between fresh and mine install, > there were discrepancies I mostly fixed, but it didn't change my > problem. > Failure looks like that in logs (pki-tomcat/acme/debug-<data>.log): > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: Finding user by cert: > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - base DN: ou=people,o=ipaca > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - filter: description=2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O= PIPEBREAKER.PL > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: User: uid=ipara,ou=people,o=ipaca > 2021-11-03 18:43:08 [https-jsse-nio-8443-exec-12] FINE: Realm.authenticate() returned false Yeah, I noticed this in your logs as well. I have no insight into what PKI does to authenticate beyond the things you've already checked. We know that this cert is ok because you can authenticate to the CA using it in other ways. It would be nice if they logged some reason for the failure to authenticate but I'm not sure how to get that. rob > > > While on _fresh install_ correct log looks like: > > 2021-10-31 13:51:47 [https-jsse-nio-8443-exec-13] INFO: Authenticating user with client certificate > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Finding user by cert: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: ou=people,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: description=2;7;CN=Certificate Authority,O=IPADEV.PIPEBREAKER.PL;CN=IPA RA,O=IPADEV.PIPEBREAKER.PL > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: User: uid=ipara,ou=people,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Getting user roles: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: ou=groups,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: uniqueMember=uid=ipara,ou=people,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Roles: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=Certificate Manager Agents,ou=groups,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=Registration Manager Agents,ou=groups,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=Enterprise ACME Administrators,ou=groups,o=ipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Initializing ACMEApplication > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: Session: 3DBCD2FB21ADFDD04ADC518C97AA07B4 > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: Principal: GenericPrincipal[ipara(Certificate Manager Agents,Enterprise ACME Administrators,Registration Manager Agents,)] > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: Principal: ipara > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: Roles: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: - Certificate Manager Agents > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: - Enterprise ACME Administrators > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: - Registration Manager Agents > 2021-10-31 13:51:48 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: LDAP: search ou=config,ou=acme,o=ipaca > 2021-10-31 13:51:49 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: ACMERequestFilter: ACME service is disabled > > > Things I've observed on fresh install, which I've implemented on my production > (it changed nothing, provided here for documentation only): > > # in /etc/pki/pki-tomcat/ca/CS.cfg: > - added lines: > features.authority.description=Lightweight CAs > features.authority.enabled=true > features.authority.version=1.0 > > - 36 profile.* lines were missing; carefully added them, for example: > profile.AdminCert.class_id=caEnrollImpl > profile.AdminCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/AdminCert.cfg > > - also copied a long line starting with profile.listprofile.list= > > - /var/lib/pki/pki-tomcat/ca/profiles/ca on prod server contained 74 files, while > fresh install had over 90. I've copied missing ones from /usr/share/pki/ca/profiles/ca/ > > # in LDAP > - ipaca / groups / Certificate Manager Agents had entry for pkidbuser; added on prod > uniqueMember: uid=pkidbuser,ou=People,o=ipaca > - pkidbuser had 3 userCertificate: entries, two of them were expired; removed those > > _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

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.