> 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 _______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users