-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/28/2014 12:56 PM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> On 07/28/2014 12:20 PM, Ade Lee wrote: >>> 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 >>>> >>>> >> >> >> >> Ok, well I tried deleting it using certutil it deletes both, I >> tried using keytool to see if it would work any better, no dice >> there. I'll try the rename, but at this point I am not holding my >> breath on that, it seems all operation are a bit too coarse. It >> seems the assumption was being made that there would only be one >> of each nickname. Which frankly makes me wonder how any of this >> kept running after the renewal. >> >> For now I'll see what I can do on a copy of the db using python. > > It is a little strange that there are multiple 'caSigningCert > cert-pki-ca' as this is the CA itself. It should be good for 20 > years and isn't something that the current renewal code handles > yet. > > You probably won't have much luck with python-nss. It can handle > reading PKCS#12 files but I don't believe it can write them (access > to key material). > > I'm not sure why certutil didn't do the trick. This should work, if > you want to give it another try. I'm assuming that /root/cacert.p12 > has the latest exported certs, adjust as necessary: > > # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d > /tmp/test # certutil -D -d /tmp/test -n '<nickname>' > > certutil should delete the oldest cert first, it always has for > me. > > rob >
And finally there is a bug open from 11 years ago (!!) that defines this problem: https://bugzilla.mozilla.org/show_bug.cgi?id=210941 It does explain to me why certutil and the like are doing what they are doing picking the latest certificate, and why things are still working in my instance. I think NES is Netscape Enterprise Server?? Man this is ancient history down in there. Any which way it looks like there was never code implemented to unambiguously identify a certificate, or if there is, it isn't user facing. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT1sQrAAoJEFg7BmJL2iPO4CoH/iV+lnoLZe1ui0ihn5EvNM0O ulgyZADLCPn/hXNcuc+//7jMSMA7qjlcopYFZedvK38HW5N8zpOENm387l4bYuVi UzFz1EjyhN7fD6C0ZzgUCL2urLQ19/ete80IZ8bP0PqXdAAEtRiR94FaUuH4h+fj Wx8z6IMnH0+B72jo+bCZqPeaDRD/rIxi23ahHOlwaqFa+W5UJ7kv2237FOpFysDE AWDYna3Na/qu6EjB5CGef2UDOeEeIdSxD5XuDY2Dl7dZo7S9tsXJZQHXTtTfg3ZH q8DHiK9j2eSaE4tukklfzrQB1cHi44hq4obRDnnFMW3mqHE0/oqhNyy/JG3zxbU= =wV5O -----END PGP SIGNATURE----- -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project