[Freeipa-users] RHEL 7 Upgrade experience so far

[Rob Crittenden]

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