On Wed, Jan 10, 2018 at 01:45:04PM +0100, Giulio Casella wrote:
Il 10/01/2018 11:01, Giulio Casella via FreeIPA-users ha scritto:
> Il 10/01/2018 10:49, Giulio Casella via FreeIPA-users ha scritto:
> > Fraser, some more info:
> >
> > In /var/log/pki/pki-tomcat/localhost_access_log.2018-01-08.txt I've
> > found:
> >
> > 172.21.251.8 - ipara [08/Jan/2018:02:03:28 +0100] "GET
> > /ca/rest/account/login HTTP/1.1" 200 218
> > 172.21.251.8 - ipara [08/Jan/2018:02:03:28 +0100] "GET
> > /ca/rest/authorities/13b94be3-f918-42e3-abeb-a2210150f28d/cert
> > HTTP/1.1" 500 6472
> > 172.21.251.8 - ipara [08/Jan/2018:02:03:28 +0100] "GET
> > /ca/rest/account/logout HTTP/1.1" 204 -
>
> It seems that someone is looking for an authority with uuid
> 13b94be3-f918-42e3-abeb-a2210150f28d.
>
> A little test with rest API (via curl) calling /ca/rest/authorities,
> reports a xml collection of authorities, composed only by one authority
> with a uuid 87f9c5e4-c7e8-4c4d-ac5e-5ee87a915576 (different from the one
> called!)
BINGO!
I tried to substitute wrong uuid in ipaCaId (dn:
cn=ipa,cn=cas,cn=ca,dc=my,dc=dom,dc=ain) with correct one in ldap, and
everything seems to work now.
Thank you Fraser and every guy that helped me solve this issue.
Cheers,
Giulio
Great! I'm glad you got to the bottom of it. Just curious - were
there / are there multiple authority entries in LDAP underneath
ou=authorities,ou=ca,o=ipaca?
I have seen this sort of problem once before, when experimenting
with changing the CA Subject DN. I wonder if the CA certificate
renewal that started all this off worked properly... are you using
an externally signed CA cert?
Thanks,
Fraser