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