[Freeipa-users] Re: RA Agent certificate authorisation fails – how to debug?

[Rob Crittenden]

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.
> > > > 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.
>
> Run that, some minor warnings, but nothing about RA cert.
>
> "source": "ipahealthcheck.ds.replication",
>     "check": "ReplicationCheck",
>     "result": "WARNING",
>     "uuid": "10a0ad23-dc7a-4f43-a5f5-fac08c55a7b9",
>     "when": "20211014120305Z",
>     "duration": "0.392689",
>     "kw": {
>       "key": "DSREPLLE0002",
>       "items": [
>         "Replication",
>         "Conflict Entries"
>       ],
>       "msg": "There were 1 conflict entries found under the replication suffix "dc=pipebreaker,dc=pl"."
>     }
>
> Not much actionable info here.
>
> {
>     "source": "ipahealthcheck.ipa.certs",
>     "check": "IPACertTracking",
>     "result": "WARNING",
>     "uuid": "e4a545a3-ad22-4b8e-b4f0-70287eae98a9",
>     "when": "20211014120309Z",
>     "duration": "2.828753",
>     "kw": {
>       "key": "20141107202922",
>       "msg": "certmonger tracking request {key} found and is not expected on an IPA master."
>     }
>   },
>
> $ getcert list -i 20141107202922
> Number of certificates and requests being tracked: 10.
> Request ID '20141107202922':
>    status: MONITORING
>    stuck: no
>    key pair storage: type=FILE,location='/etc/pki/tls/private/kaitain.pipebreaker.pl.key'
>    certificate: type=FILE,location='/etc/pki/tls/certs/kaitain.pipebreaker.pl.crt'
>    CA: IPA
>    issuer: CN=Certificate Authority,O=PIPEBREAKER.PL
>    subject: CN=kaitain.pipebreaker.pl,O=PIPEBREAKER.PL
>    issued: 2020-08-24 06:23:58 CEST
>    expires: 2022-08-25 06:23:58 CEST
>    dns: kaitain.pipebreaker.pl
>    principal name: host/[e-mail]
>    key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>    eku: id-kp-serverAuth,id-kp-clientAuth
>    pre-save command: 
>    post-save command: 
>    track: yes
>    auto-renew: yes
>
> Looks fine, I have this cert/key configured in systemd-journal-upload service,
> this is not a part of FreeIPA.
>
> {
>     "source": "ipahealthcheck.ipa.certs",
>     "check": "IPACertDNSSAN",
>     "result": "ERROR",
>     "uuid": "87699232-f56d-47e4-802b-afab4f1d1b9b",
>     "when": "20211014120312Z",
>     "duration": "2.300274",
>     "kw": {
>       "key": "20200624045303",
>       "hostname": "kaitain.pipebreaker.pl",
>       "san": [],
>       "ca": "IPA",
>       "profile": "caIPAserviceCert",
>       "msg": "Certificate request id {key} with profile {profile} for CA {ca} does not have a DNS SAN {san} matching name {hostname}"
>     }
>   }
> ]
>
> $ getcert list -i 20200624045303
> Number of certificates and requests being tracked: 10.
> Request ID '20200624045303':
>    status: MONITORING
>    stuck: no
>    key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PIPEBREAKER-PL',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PIPEBREAKER-PL/pwdfile.txt'
>    certificate: type=NSSDB,location='/etc/dirsrv/slapd-PIPEBREAKER-PL',nickname='Server-Cert',token='NSS Certificate DB'
>    CA: IPA
>    issuer: CN=Certificate Authority,O=PIPEBREAKER.PL
>    subject: CN=kaitain.pipebreaker.pl,O=PIPEBREAKER.PL
>    issued: 2021-08-18 14:27:32 CEST
>    expires: 2023-08-19 14:27:32 CEST
>    principal name: ldap/[e-mail]
>    key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>    eku: id-kp-serverAuth,id-kp-clientAuth
>    profile: caIPAserviceCert
>    pre-save command: 
>    post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv PIPEBREAKER-PL
>    track: yes
>    auto-renew: y
>
> Also looks fine, SAN requirement in certificates only appeared few years ago, after
> this particular server was installed.  I doubt it is even used in context of LDAP connection.
> > Does the RA cert work in other contexts? Does ipa cert-find work? Can
> > you request a test certificate?
>
> It looks so:
>
> root@kaitain ~$ ipa cert-find
> ipa: ERROR: did not receive Kerberos credentials
>
> root@kaitain ~$ kinit admin
> Password for [e-mail]:
>
> root@kaitain ~$ ipa cert-find
> ipa: WARNING: Search result has been truncated: Configured size limit exceeded
> 100 certificates matched
>
> [ … hundred certificates listed … ]
>
> When I check in WebUI I see that latest certificate was
> Issued On
> Tue Oct 05 20:27:05 2021 UTC
>
> So it worked last week.
>
> What would be 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

rob