[Pki-devel] [PATCH] TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca [20140225]

[Ade Lee]

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:
> Matt, 
> 
> Have you done a cloning test without the above patch?  You can do so by
> implementing the workaround.  In this case, does the DS replication
> issue still arise?
> 
> Ade
> 
> On Tue, 2014-02-25 at 17:31 -0800, Matthew Harmsen wrote:
> > 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
> > 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 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.
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel