[Freeipa-users] RHEL 7 Upgrade experience so far

[Erinn Looney-Triggs]

-----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-----