Where is root CA private key stored?

[Ian Pilcher]

(Hopefully Thunderbird will only send one copy of this.  Sorry about the
previous duplicate.)

I run a single FreeIPA server (on CentOS 7) in my home network, and I'm
thinking of migrating it to Fedora.  AFAICT, doing this as an actual
upgrade will require multiple cycles of creating a newer FreeIPA server,
adding it as a replica, removing the older server, lather, rinse,
repeat.

I'm only using FreeIPA for its DNS, certificate authority, and LDAP
authentication capabilities, and my home network isn't that large, so
I'm considering simply installing a new server and re-creating the
various users, hosts, services, and DNS zones/entries.  (I don't have
any systems that are truly managed with FreeIPA.)

Thus, it would be nice if the new FreeIPA server could use the same
root CA certificate as the existing one.  I believe that I can do this
by passing the --external-cert-file option to ipa-server-install, but
I need both the certificate and the private key of the root CA to do so.

Thus, I'm wondering how I can extract the root CA private key from my
existing CentOS 7 (FreeIPA 4.6.8) server.

Thanks!

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

[Rob Crittenden]

Ian Pilcher via FreeIPA-users wrote:
>  (Hopefully Thunderbird will only send one copy of this.  Sorry about
> the
>  previous duplicate.)
>  
>  I run a single FreeIPA server (on CentOS 7) in my home network, and I'm
>  thinking of migrating it to Fedora.  AFAICT, doing this as an actual
>  upgrade will require multiple cycles of creating a newer FreeIPA server,
>  adding it as a replica, removing the older server, lather, rinse,
>  repeat.
>  
>  I'm only using FreeIPA for its DNS, certificate authority, and LDAP
>  authentication capabilities, and my home network isn't that large, so
>  I'm considering simply installing a new server and re-creating the
>  various users, hosts, services, and DNS zones/entries.  (I don't have
>  any systems that are truly managed with FreeIPA.)
>  
>  Thus, it would be nice if the new FreeIPA server could use the same
>  root CA certificate as the existing one.  I believe that I can do this
>  by passing the --external-cert-file option to ipa-server-install, but
>  I need both the certificate and the private key of the root CA to do so.
>  
>  Thus, I'm wondering how I can extract the root CA private key from my
>  existing CentOS 7 (FreeIPA 4.6.8) server. 
One reason for the RHEL 7 -> RHEL 8 -> RHEL 9 migration requirement is
due to crypto changes between them. You'd probably have the same issue
trying to create a replica from a RHEL 7 server unless you tweaked the
crypto policy and even then I'm not sure it would work.

The CA is stored in the NSS database /etc/pki/pki-tomcat/alias. You can
use pk12util to extract it into a PKCS#12, then extract that and you'll
have the CA. This would keep the CA trust the same but with a fresh
install you'd need new keytabs for any enrolled clients.

rob

[Ian Pilcher]

On 6/30/23 12:38, Rob Crittenden wrote:
>  The CA is stored in the NSS database /etc/pki/pki-tomcat/alias. You
> can
>  use pk12util to extract it into a PKCS#12, then extract that and you'll
>  have the CA. This would keep the CA trust the same but with a fresh
>  install you'd need new keytabs for any enrolled clients. 
Perfect.  Thanks!

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

[Ian Pilcher]

On 6/30/23 12:38, Rob Crittenden wrote:
>  The CA is stored in the NSS database /etc/pki/pki-tomcat/alias. You
> can
>  use pk12util to extract it into a PKCS#12, then extract that and you'll
>  have the CA. This would keep the CA trust the same but with a fresh
>  install you'd need new keytabs for any enrolled clients. 
FYI< I ran into an issue trying to re-use the root CA from the existing
install.  ipa-server-install won't accept the --external-cert-file
option unless it's previously been run with --external-ca.  And, of
course, the pre-existing CA certificate and key don't match the CSR
(and presumably the private key) that are used to create the CSR.

I'm starting to suspect that it will be easier to just accept that I'm
going to have to use a new root CA, rather than trying to re-use the old
one.

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

[Rob Crittenden]

Ian Pilcher wrote:
>  On 6/30/23 12:38, Rob Crittenden wrote:
> > The CA is stored in the NSS database /etc/pki/pki-tomcat/alias. You can
> > use pk12util to extract it into a PKCS#12, then extract that and you'll
> > have the CA. This would keep the CA trust the same but with a fresh
> > install you'd need new keytabs for any enrolled clients.
>  
>  FYI< I ran into an issue trying to re-use the root CA from the existing
>  install.  ipa-server-install won't accept the --external-cert-file
>  option unless it's previously been run with --external-ca.  And, of
>  course, the pre-existing CA certificate and key don't match the CSR
>  (and presumably the private key) that are used to create the CSR.
>  
>  I'm starting to suspect that it will be easier to just accept that I'm
>  going to have to use a new root CA, rather than trying to re-use the old
>  one.
>   
IPA doesn't support providing an existing CA cert and key to bootstrap
the install. In this case the new install will be an external CA with
that CA being your previous cert and key. You'll need to roll your own
signing using the private key.

I forgot to mention that if you're using the same domain/realm
combination you'll need to use the --subject-base option with the new
install so that the "new" IPA CA subject is different from the previous one.

rob