[Freeipa-users] RHEL 7 Upgrade experience so far

[Ade Lee]

On Mon, 2014-07-28 at 12:14 -0700, Erinn Looney-Triggs wrote:
> On 07/28/2014 11:07 AM, Ade Lee wrote:
> >> 
> >> No exceptions thrown in the journal.
> >> 
> >> When investigating the cacert.p12 file that is bundled up for
> >> the replica's I see two caSigningCert's. One is the older one,
> >> before I renewed and one is the new, valid, post renewal one. Are
> >> these the certs that are used or are they requested from the
> >> primary much like the servercert?
> > 
> > I think the problem might be that there are two caSigningCerts,
> > with presumably the same nickname.  We need to try and generate a
> > p12 file without the old pre-renewal signing cert.
> > 
> > Does the master certdb contain both certs with the same nickname? 
> > If so, you could try to remove the old signing cert from the
> > master certdb and then regenerate the pkcs12 using PKCS12Export.
> > 
> > Here is one way you could try to do this: 1. Export the caSigning
> > cert from the certdb using pk12util.  Check that only the latest
> > cert/key has been exported.  Make sure to note down the exact cert
> > nickname.  If so, then continue .. 2. Shut down the CA. 3.
> > IMPORTANT: Back up the certdb. 4. Delete the caSigning cert from
> > the certdb using certutil.  You may have to do this twice to remove
> > both certs. 5. Re-import the saved caSigningCert using pk12util. 6.
> > Restart the CA.
> > 
> >> 
> >> However, when examining the /etc/pki/pki-tomcat/alias db there is
> >> no casigningcert, hence I suppose the failure. So somewhere in
> >> there it is getting lost, I'll keep looking but throw me any
> >> ideas.
> >> 
> > By this, you are implying looking at the clone certdb, right?  The
> > cert should certainly still exist on the master.  The cert not
> > being in the clone certdb is because it fails to be imported from
> > the PKCS12 file.
> > 
> > 
> >> -Erinn
> >> 
> >> 
> >> 
> 
> Ok to make sure we are on the same page and I am not chasing my own
> tail here, I am going to recap this as I understand the issue now.
> 
> Essentially, we get a cacert.p12 file on the master IPA server that
> was generated using: PKCS12Export -d $ALIAS_PATH -p /root/keydb_pin -w
> /root/dm_password -o /root/cacert.p12
> 
> This cacert.p12 file contains multiple copies of certificates, both
> expired and valid, for, well, multiple aliases in fact not just the
> caSigningCert.
> 
> Nevertheless, because of these multiple copies of the caSigningCert we
> are venturing a guess that this is munging up the ca clone on the
> replica (a fair guess I would say). So there is probably a bug in here
> somewhere, either on the exporting end, or on the importing end.
> 
> So, I/we are trying to use the userspace tools to basically clean up
> the NSS db to only have the valid copy of this certificate.
> 
> However, it appears to me that most of these tools are not granular
> enough in their selection, the export everyhing with an alias of
> 'caSigningCert cert-pki-ca' or delete all instance of 'caSigningCert
> cert-pki-ca'. Kind of a sledgehammer for a penny nail type thing. Does
> this sound about right?
> 
> If so, it looks like a more granular approach is warranted. I'll be
> looking into python-nss as python is what I know best to see if I can
> hack up something to whip the DB into proper shape.
> 
> Anything I am missing here? Sound like a reasonable approach?
> 
That sounds exactly right.  

You could try deleting the cert using certutil -D (make sure to back up
the certdb first) and see if it will delete one or both certificates.
Or you could try renaming the cert nick using certutil and see if it
renames just one.

Ade
> -Erinn
> 
>