[Freeipa-users] RHEL 7 Upgrade experience so far

[Erinn Looney-Triggs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

- -Erinn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJT1qY0AAoJEFg7BmJL2iPOTpgH/0WSF7Hd1UI1plhfKECnM62P
zXIGVXb6SI+zy8txsjL9XPRndmy+TEFdxw858PuPJSWaGt0JNPk4uVZ8I3fa4ekS
aT5qedSyaSDMI6bNSyo8LSHap2J2CY/eNrGPHIQk31RvXCH9C8vnrbRIiDcKmVYH
UliRpntYUnuyAlIc91unkIaGJHQ4BAgCQ2gSzv40Ub9exhhTgLwguLnD1N9w0qgl
HjQrLTuLvbDDu/FYlcW9uBr16iSriw71yZyPZ4KnyOO50yP+MjHcjoXpw5d5WLc3
qYSMLRHpWHAKkyxwhz6472XfRjP+lg6zCLzB+O2/A3BbHzX9eVgI4pkC02u1Uhg=
=XPfQ
-----END PGP SIGNATURE-----