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

Wed May 23 17:23:10 UTC 2012

On 05/23/2012 08:59 AM, James Hogarth wrote:
>> 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
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

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.

General information about related Dogtag CA default configuration:

  * CRL generation is by default enabled.
    *ca.crl.<issuingPointId>.enableCRLUpdates=true
    *Absence of the above line is a equivalent to **CRL generation being
    enabled.

  * CRL cache is by default enabled.
    *ca.crl.<issuingPointId>.enableCRLCache=true
    *Absence of the above line is a equivalent to **CRL cache being enabled.

  * 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

  * 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.

  * Redirection of CRL generation requests is by default disabled.
    *master.ca.agent.host=/|<hostName>|/
    **master.ca.agent.port=/|<portNumber>|/
    ***Absence of the above lines is a equivalent to**redirection of CRL
    generation
    requests being disabled.

1. Installation of first IPA should configure Dogtag CA generating CRLs:

    Default CA installation includes CRL issuing point generating CRLs.
    Monitoring of database replications for the purpose of updating CRL
    cache
    can be added assuming that CA will be cloned, by setting
    *ca.listenToCloneModifications=true*

2. Installation of IPA's clone shouldconfigure Dogtag CA with CRL 
generation disabled:

    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=/|<hostName>|/
    **master.ca.agent.port=/|<portNumber>
    |/*This *step* can be *optional* if IPA will not issue "manual" CRL
    generation requests.
    *
    *CA's database maintenance thread can be disabled by setting
    *ca.certStatusUpdateInterval=0
    *This *step* can be *optional* if each clone can verify certificate
    expiration independently.

3. Transferring CRL generation to another clone:

    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 in new CA by applying
    differences from default configuration providedin *(1)*.

Thank you,
Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120523/4b9c79c7/attachment.htm>