Migrating IPA CA to new hosts

[Adam Bishop]

We're in the process of decomissioning our oldest IPA servers (built in 2014).
We've migrated the roles successfully and are making sure everything is ready to
switch over to the new set, and just wanted to check a few observations/inconsistencies.

* On some of our newer clients /etc/ipa/ca.crt contains the root and the server
certificate of the enrolment server instead of just the root - did the behaviour  of
ipa-client-install change at some point?

* Our root contains the OCSP URI of one of the servers to be decomissioned in the
Authority Information Access field. My understanding is that a client would never do an
OCSP lookup on a root certificate so do we need to re-sign or add a CNAME prior to
switching off?

* When enroling a client, ipa-client-install pulls down an expired RA certificate -
however /var/lib/ipa/ra-agent.pem on all servers is current. Where might the expired cert
be stored? Doesn't appear to cause an issue in any case.

Adam

[Rob Crittenden]

Adam Bishop via FreeIPA-users wrote:
>  We're in the process of decomissioning our oldest IPA servers
> (built in 2014). We've migrated the roles successfully and are making sure everything
> is ready to switch over to the new set, and just wanted to check a few
> observations/inconsistencies. 
Migrating from what to what version?

>  
>  * On some of our newer clients /etc/ipa/ca.crt contains the root and the server
> certificate of the enrolment server instead of just the root - did the behaviour  of
> ipa-client-install change at some point? 
What version of the client? Can we see the client install log?

>  * Our root contains the OCSP URI of one of the servers to be
> decomissioned in the Authority Information Access field. My understanding is that a client
> would never do an OCSP lookup on a root certificate so do we need to re-sign or add a
> CNAME prior to switching off? 
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.

>  * When enroling a client, ipa-client-install pulls down an expired RA
> certificate - however /var/lib/ipa/ra-agent.pem on all servers is current. Where might the
> expired cert be stored? Doesn't appear to cause an issue in any case. 
Can we see the client install log? It should never attempt to pull the
RA certificate.

rob

[Adam Bishop]

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.

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

[Florence Blanc-Renaud]

Hi,

On Tue, Apr 26, 2022 at 8:29 PM Adam Bishop via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org&gt; 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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Adam Bishop]

>  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. 
Thanks, I've checked the location and corrected the files - last modified date was
2014 so not sure if it was an unintended change by a staff member, or a bug during an
upgrade.

Thanks for the assistance, I'm now happy that the behaviour of our old and new servers
is consistent, so the decomissioning should be uneventful.

Adam

[Florence Blanc-Renaud]

On Mon, Apr 25, 2022 at 5:01 AM Adam Bishop via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org&gt; wrote:

>  We're in the process of decomissioning our oldest IPA servers
> (built in
>  2014). We've migrated the roles successfully and are making sure everything
>  is ready to switch over to the new set, and just wanted to check a few
>  observations/inconsistencies.
>
>  * On some of our newer clients /etc/ipa/ca.crt contains the root and the
>  server certificate of the enrolment server instead of just the root - did
>  the behaviour  of ipa-client-install change at some point?
>
>  Hi, 
I just want to make sure we are using the same terminology. When you refer
to the root certificate, do you mean that IPA was installed with an
externally signed CA? If that's the case, it's expected that
/etc/ipa/ca.crt contains both the external CA and IPA CA.
Or are you referring to IPA CA?


>  * Our root contains the OCSP URI of one of the servers to be
> decomissioned
>  in the Authority Information Access field. My understanding is that a
>  client would never do an OCSP lookup on a root certificate so do we need to
>  re-sign or add a CNAME prior to switching off?
>
>  * When enroling a client, ipa-client-install pulls down an expired RA
>  certificate - however /var/lib/ipa/ra-agent.pem on all servers is current.
>  Where might the expired cert be stored? Doesn't appear to cause an issue in
>  any case.
>  
Where do you see this expired RA certificate? Clients do not have any RA
certificate, only servers do.

flo

>  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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Adam Bishop]

>  I just want to make sure we are using the same terminology. When you
> refer
>  to the root certificate, do you mean that IPA was installed with an
>  externally signed CA? If that's the case, it's expected that
>  /etc/ipa/ca.crt contains both the external CA and IPA CA.
>  Or are you referring to IPA CA? 
Referring to the IPA CA - we don't have the root externally signed.

>  Where do you see this expired RA certificate? Clients do not have any
> RA
>  certificate, only servers do. 
It's during the client install process (and, subsequently, in /etc/ipa/ca.crt).
Rob's comment above gave me enough of a clue to figure out that the server
shouldn't be doing that and that the two cert issues are actually the same issue - the
old servers seem to be serving up additional certs erroneously, but the new ones behave
correctly.

Adam