[Freeipa-users] PKI Subsystem Type: CA Clone convert to Root

[James Hogarth]

> I'll see if I can get one of the dogtag guys to take a look at this.
>
> In general, this is not really a big problem. All we are doing here is deciding which of the CAs will generate the CRL. You want just one because other operations are happening at the same time, potentially on other CAs, and if they are all generating a CRL at more or less the same time then resulting CRLs could be different by a cert or two. For consistency sake it is better to do this one one machine and publish it.
>
> Other than that there is no "master" promotion required. All of the servers, particularly those with a CA installed, are equals.

Just joined the list following looking in the archives - so apologies
for the random quote from a post yesterday....

This has left me quite confused compared to my infrastructure and
directly impacts me as I need to take the first IPA install offline
indefinitely....

On the first system a service pki-cad status shows:
PKI Instance Name:   pki-ca
PKI Subsystem Type:  Root CA (Security Domain)

On the three systems built subsequently (with dns and CA replica
install options) the following is shown:

PKI Instance Name:   pki-ca
PKI Subsystem Type:  CA Clone (Security Domain)

The section 18.8.1 of the Identity Guide on the docs.redhat.com site
refers to entries such as:
ca.listenToCloneModifications=true
master.ca.agent.host=hostname
master.ca.agent.port=port number

However on none of my four IPA instances do these lines appear in CS.cfg ....

So far as I can see from ipa-csmanage-replica list the initial system
has a replica agreement with each of the other three but no agreements
exist between those other three themselves (ie all replication has to
go through the initial system).

This is a fully updated CentOS 6 system... IPA/PKI packages in the rpmdb:
ipa-server-selinux-2.1.3-9.el6.x86_64
libipa_hbac-1.5.1-66.el6_2.3.x86_64
libipa_hbac-python-1.5.1-66.el6_2.3.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-admintools-2.1.3-9.el6.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-python-2.1.3-9.el6.x86_64
ipa-client-2.1.3-9.el6.x86_64
ipa-server-2.1.3-9.el6.x86_64
pki-java-tools-9.0.3-21.el6_2.noarch
pki-common-9.0.3-21.el6_2.noarch
pki-symkey-9.0.3-21.el6_2.x86_64
pki-util-9.0.3-21.el6_2.noarch
pki-ca-9.0.3-21.el6_2.noarch
pki-setup-9.0.3-21.el6_2.noarch
pki-silent-9.0.3-21.el6_2.noarch
pki-native-tools-9.0.3-21.el6_2.x86_64
pki-selinux-9.0.3-21.el6_2.noarch
krb5-pkinit-openssl-1.9-22.el6_2.1.x86_64

I can't quite reconcile all the above with the discussions on the
mailing list of how no promoting is needed in a dogtag (as opposed to
self signed) IPA replication topology....

So far as I can see at a minimum when the first server gets switched
off the other three will no longer exchange certificate information
and there might be CRL issues too?

Is there any tested procedure to go from a 'Clone' to a 'Root'
instance for the CAs (and sort out the replication agreements in the
process) in IPA 2.1/2.2?

Kind regards,

James Hogarth