Note: This patch is intended for Dogtag 10.1. Once approved, it will also need to be applied to the 'master' branch. -------- Original Message -------- Subject: [Pki-devel] [PATCH] TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca [20140225] Date: Tue, 25 Feb 2014 17:31:50 -0800 From: Matthew Harmsen <mharmsen(a)redhat.com&gt; To: pki-devel <pki-devel(a)redhat.com&gt; This patch causes the 'sslserver' certificate for a CA clone to be signed by its associated master CA during configuration, and resolves the following bug: * Dogtag TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca <https://fedorahosted.org/pki/ticket/816> This was necessary to avoid any changes which may have been made to the X500Name directory string encoding order (i. e. - creating a Cloned CA on Fedora 20 from a Master CA on Fedora 19). The code was tested (applying the CAVEAT below) via end-to-end 'pkispawn' installation and batch-based configuration; it has not yet been tested with GUI-based configuration. *CAVEAT:* During the preparation of this patch it was discovered that an end-to-end test of functionality cannot be accomplished due to the 389 TRAC Ticket #47721 - Schema Replication Issue <https://fedorahosted.org/389/ticket/47721> which prevents the '99user.ldif' file from being properly replicated from the Master CA to the Cloned CA. However, I verified that this code does work by shutting down DS on the cloned CA machine, manually replacing '/etc/dirsrv/slapd-<clone>/schema/99user.ldif' with '/etc/dirsrv/slapd-<master>/schema/99user.ldif, restarting DS and the Cloned CA, and successfully performing a test enrollment.

Matt, The patch itself is relatively straightfoward and does roughly what I would have expected the patch to do. It is, however, somewhat confusing - in no small part because the code in this section is quite convoluted. and not easy to understand. 1. In the initial part of the patch, you retrieve and temporarily store one CS,cfg value, modify a few others and set some values for this particular cert object - but only if you are cloning a CA. I think its clearer to something like this: String selection = config.getString(...) String csType = config.getString(...) if csType.equals("CA") && selection.equals("clone") && certTag.equals("sslserver") { rather than using nested if statements. 2. You set some parameters like preop.cert.signing.type and preop.cert.signing.profile in this code, but do not unset them once processing the sslserver cert. Now this function is called for each certificate in the cert.list. That means that these parameters will have different values (potentially) depending on the order of parameters in the cert.list. Does this happen? Does it matter? 3. You set a value preop.ca.type to "master_ca", and essentially copy the section for "sdca", substituting the master hostname and port for the CA hostname and port. As we already discussed in #irc, "sdca" does not mean "security domain ca". It means "ca which is in the security domain". As such, the clone circumstance is just a special case of "sdca". A better approach might be to not create a new section for "master_ca", but rather to reuse the "sdca" section, using a boolean to set the correct ca hostname. Something like this perhaps (in pseudo-code) if (select == "clone") && (csType == "ca") && (certTag == "sslServer") { // set relevant parameters cloningCA = true; } ... if caType.equals("remote") { ... if (certTag == subsystem) { ... -> go security domain CA } else if (sdca) { if cloningCA { set hostname = ca master hostname set port = ca master port } else { ... } ... if (cloningCA) { revert any needed params? } 4. Of course, we need to figure out why its not working with the UI side. Ade On Wed, 2014-02-26 at 10:07 -0500, Ade Lee wrote: