<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <tt>On 05/23/2012 08:59 AM, James Hogarth wrote:</tt> <blockquote cite="mid:CAGkb5vdY-dTYE6BJiMzDHTos1vvWbQy=QYfzCkzBmqw3MrAmwA@mail.gmail.com" type="cite"> <blockquote type="cite"> <pre wrap=""><tt>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. </tt></pre> </blockquote> <pre wrap=""><tt> 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 <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a> </tt></pre> </blockquote> <tt> They are identical CAs so calling one of them 'Root' and others 'Clone' is quite misleading. One of Dogtag CAs is selected to produce CRLs to have consistent source of revocation information. CRL generation is one of many Dogtag CA options and enabling or disabling this option does not make selected CA 'Root' or 'Clone'. Here is an information on Dogtag CA configuration which should help to clear confusion. </tt><tt>General information about related Dogtag CA default configuration: </tt> <ul> <li><tt>CRL generation is by default enabled. ca.crl.<issuingPointId>.enableCRLUpdates=true Absence of the above line is a equivalent to CRL generation being enabled. </tt> </li> <li><tt>CRL cache is by default enabled. ca.crl.<issuingPointId>.enableCRLCache=true Absence of the above line is a equivalent to CRL cache being enabled. </tt> </li> <li><tt>CA's database maintenance thread is controlled by setting its interval. Its default value is 10 minutes set by the following line: ca.certStatusUpdateInterval=600 Absence of the above line is a equivalent to setting database maintenance thread interval to 10 minutes. CA's database maintenance thread can be disabled by setting its interval to zero: ca.certStatusUpdateInterval=0 </tt> </li> <li><tt>Monitoring of database replications for the purpose of updating CRL cache is by default disabled. ca.listenToCloneModifications=false Absence of the above line is a equivalent to disabled monitoring of database replications. </tt> </li> <li><tt>Redirection of CRL generation requests is by default disabled. master.ca.agent.host=<code><hostName></code> master.ca.agent.port=<code><portNumber></code> Absence of the above lines is a equivalent to redirection of CRL generation requests being disabled. </tt> </li> </ul> <tt> 1. Installation of first IPA should configure Dogtag CA generating CRLs: </tt> <blockquote><tt>Default CA installation includes CRL issuing point generating CRLs. Monitoring of database replications </tt><tt>for the purpose </tt><tt>of updating CRL cache </tt><tt>can be added assuming that CA will be cloned, by setting ca.listenToCloneModifications=true </tt></blockquote> <tt> 2. Installation of IPA's clone </tt><tt>should</tt><tt> configure Dogtag CA with CRL generation disabled: </tt> <blockquote><tt>CRL generation can be disabled by setting ca.crl.<issuingPointId>.enableCRLUpdates=false Redirection of CRL generation requests can be enabled by setting master.ca.agent.host=<code><hostName></code> master.ca.agent.port=<code><portNumber> </code>This step can be optional if IPA will not issue </tt><tt>"manual" CRL generation requests. CA's database maintenance thread can be </tt><tt>disabled by setting ca.certStatusUpdateInterval=0 This step can be optional if each clone can verify certificate expiration independently. </tt></blockquote> <tt> 3. Transferring CRL generation to another clone: </tt> <blockquote><tt>CRL generation can be transfer from one CA clone to another by disabling CRL generation in CA currently issuing CRLs using differences from default configuration provided in (2) and enabling CRL generation </tt><tt></tt><tt>in new CA by applying</tt> <tt>differences from default configuration provided</tt><tt> in (1).</tt></blockquote> <tt> Thank you, Andrew </tt> <pre wrap=""><tt> </tt></pre> </body> </html>