Hi,
On Tue, Apr 26, 2022 at 8:29 PM Adam Bishop via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
Thanks for your reply,
Rob Crittenden via FreeIPA-users wrote:
> Migrating from what to what version?
Our old ones were built on whatever shipped with RHEL 7.0, but they're
currently running 4.6.8 The new set are running 4.9.6.
> What version of the client? Can we see the client install log?
See below - while gathering a client log, I realised this is the same
issue as the expired RA cert below rather than a seperate issue.
> OSCP is not enabled on IPA clients by default but that doesn't mean it
> can never be used. I'd add a CNAME to be on the safe side.
We're not running anything exciting, so the defaults should still apply -
I'll add a CNAME to be safe as recommended, thanks.
> Can we see the client install log? It should never attempt to pull the
> RA certificate.
The behaviour is a little more complex than I thought. My assumption was
that the RA cert being pulled down was intentional, and therefore the issue
was that an older version was being served up. With your comment in mind, I
dug deeper:
* oldipa1 is serving up the root CA and an expired version of its own
server cert
* oldipa2 is serving up the root CA and an expired version of the RA cert
> Do you want to download the CA cert from
http://oldipa1.example/ipa/config/ca.crt ?
> (this is INSECURE) [no]: yes
> trying to retrieve CA cert via HTTP from
http://oldipa1.example/ipa/config/ca.crt
> Starting external process
> args=['/usr/bin/curl', '-o', '-', '
http://oldipa1.example/ipa/config/ca.crt']
> Process finished, return code=0
> stdout=-----BEGIN CERTIFICATE-----
> <snip>
> -----END CERTIFICATE-----
> -----BEGIN CERTIFICATE-----
> <snip>
> -----END CERTIFICATE-----
>
> stderr= % Total % Received % Xferd Average Speed Time Time
Time Current
> Dload Upload Total Spent Left
Speed
> 100 2818 100 2818 0 0 62622 0 --:--:-- --:--:-- --:--:--
62622
>
> Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=EXAMPLE
> Issuer: CN=Certificate Authority,O=EXAMPLE
> Valid From: 2014-09-23 16:52:33
> Valid Until: 2034-09-23 16:52:33
>
> Subject: CN=oldipa1.example,O=EXAMPLE
> Issuer: CN=Certificate Authority,O=EXAMPLE
> Valid From: 2014-09-29 10:56:23
> Valid Until: 2016-09-29 10:56:23
Forcing the ipa-client-install to use one of the new servers results in
only the root being downloaded as expected so it doesn't look like we need
to fix anything prior to the switch off, other than to just satisfy my
curiosity as to how the old servers got into their current state.
From where on disk does the certificate get pulled from when it's
downloaded by the installer? I'm guessing it's just somehow had extra
things written to the end of it.
As can be seen in the logs, the installer downloads the cert from
http://oldipa1.example/ipa/config/ca.crt. The file
/etc/httpd/conf.d/ipa.conf on the server contains this setting:
Alias /ipa/config "/usr/share/ipa/html"
which means that the file ca.crt is stored in /usr/share/ipa/html/ca.crt.
This file is updated by ipa-certupdate when a new CA is added, but it
should only contain CA certificates, not the RA cert or a server cert.
flo
I've uploaded the full client log here as I can't see how to attach via
hyperkitty:
https://jisc365-my.sharepoint.com/personal/adam_bishop_jisc_ac_uk/_layout...
Thanks for your help,
Adam
_______________________________________________
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