[Freeipa-users] RHEL 7 Upgrade experience so far

Erinn Looney-Triggs erinn.looneytriggs at gmail.com
Mon Jul 28 20:36:28 UTC 2014


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

Well I reckon you don't issue certificates that are longer than the
lifetime of the subordinate CA right? By default, the subordinate that
is issued by AD CS is for 2 years, though you can adjust that in the
registry.

Anyway, I pulled a copy of the alias db, ran certutil -D against it
and it deleted the newest cert unfortunately, though not all of them
as I thought it had before. I'll keep experimenting around.

Here is what I got:
certutil -L -d alias

Certificate Nickname                                         Trust
Attributes

SSL,S/MIME,JAR/XPI

exampleLLC - com                                           CT,c,
subsystemCert cert-pki-ca                                    u,u,u
ocspSigningCert cert-pki-ca                                  u,u,u
caSigningCert cert-pki-ca                                    CTu,Cu,Cu
ocspSigningCert cert-pki-ca                                  u,u,u
subsystemCert cert-pki-ca                                    u,u,u
ocspSigningCert cert-pki-ca                                  u,u,u
ocspSigningCert cert-pki-ca                                  u,u,u
caSigningCert cert-pki-ca                                    CTu,Cu,Cu
Server-Cert cert-pki-ca                                      u,u,u
auditSigningCert cert-pki-ca                                 u,u,Pu

certutil -D -d alias -n 'caSigningCert cert-pki-ca'

certutil -L -d alias

Certificate Nickname                                         Trust
Attributes

SSL,S/MIME,JAR/XPI

exampleLLC - com                                           CT,c,
subsystemCert cert-pki-ca                                    u,u,u
ocspSigningCert cert-pki-ca                                  u,u,u
caSigningCert cert-pki-ca                                    CTu,Cu,Cu
ocspSigningCert cert-pki-ca                                  u,u,u
subsystemCert cert-pki-ca                                    u,u,u
ocspSigningCert cert-pki-ca                                  u,u,u
ocspSigningCert cert-pki-ca                                  u,u,u
Server-Cert cert-pki-ca                                      u,u,u
auditSigningCert cert-pki-ca                                 u,u,Pu


certutil -L -d alias -n 'caSigningCert cert-pki-ca'
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            12:d2:fd:cd:00:00:00:00:0c:ea
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=exampleLLC,DC=example,DC=com"
        Validity:
            Not Before: Sat Dec 10 03:13:26 2011
            Not After : Tue Dec 10 03:23:26 2013
        Subject: "CN=Certificate Authority,O=example.COM"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    b2:0e:65:37:df:c4:fe:ee:ba:e8:ee:77:40:a0:ff:27:
                    ab:46:3f:23:e8:ce:69:e0:f1:25:1f:98:09:a1:18:c0:
                    b2:bc:f6:d7:36:bd:a2:e3:96:02:2e:8a:d5:99:d5:d3:
                    73:f7:1b:33:58:78:0a:60:c9:22:89:5b:88:57:2f:eb:
                    a3:c8:70:6f:2e:c8:31:8f:87:19:b2:e7:7c:c4:f0:41:
                    ca:7c:c7:ab:5b:bc:b1:d7:ec:15:9c:f3:9f:19:36:0f:
                    ce:1b:3e:5b:cc:a9:04:da:2b:ef:09:17:fb:82:cc:21:
                    db:d3:76:31:c2:31:b6:52:f7:73:06:2d:c6:c5:de:75:
                    bc:b6:13:97:57:45:d8:67:67:84:c1:cd:0e:d7:20:ae:
                    2a:05:48:ad:21:ab:32:2f:d1:6d:e4:62:01:8f:fd:46:
                    52:dd:14:c3:b9:be:36:e4:0e:77:1c:14:af:97:5f:db:
                    e0:c2:2a:ae:47:dc:fa:2b:e7:4f:f5:69:6f:4c:94:f0:
                    f2:c0:c7:20:ed:55:51:7e:c8:4c:12:5d:ef:e9:dd:c0:
                    27:26:bc:74:c8:5b:c4:72:33:89:42:20:12:d3:d6:e6:
                    e3:96:cd:9b:9e:22:76:fd:e3:8d:b7:8c:6a:10:0c:d9:
                    da:cc:02:ca:ed:9d:f0:aa:3b:eb:37:a3:03:a5:83:6f
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name: Certificate Subject Key ID
            Data:
                ac:c0:a2:55:32:b7:b8:ab:59:58:17:4e:86:b6:34:5b:
                29:b3:4a:c1

            Name: Certificate Authority Key Identifier
            Key ID:
                d0:22:e6:99:b9:22:67:cf:40:c3:c7:9f:ec:72:65:fa:
                92:a0:4c:93

            Name: CRL Distribution Points
            Distribution point:
                URI:
"ldap:///CN=exampleLLC,CN=DC001,CN=CDP,CN=Public%20Key

%20Services,CN=Services,CN=Configuration,DC=example,DC=

com?certificateRevocationList?base?objectClass=cRLDistrib
                    utionPoint"

            Name: Authority Information Access
            Method: PKIX CA issuers access method
            Location:
                URI:
"ldap:///CN=exampleLLC,CN=AIA,CN=Public%20Key%20Servic

es,CN=Services,CN=Configuration,DC=example,DC=com?cACer
                    tificate?base?objectClass=certificationAuthority"

            Name: Microsoft Enrollment Cert Type Extension
            Data: "SubCA"

            Name: Certificate Basic Constraints
            Critical: True
            Data: Is a CA with no maximum path length.

            Name: Certificate Key Usage
            Critical: True
            Usages: Digital Signature
                    Certificate Signing
                    CRL Signing

    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
    Signature:
        24:89:71:f5:06:bd:e5:2f:4f:06:e3:12:00:86:12:4f:
        c9:69:5b:16:49:9f:cb:b6:d8:ef:52:8e:7e:00:1e:d7:
        88:00:a4:5a:54:dd:d6:df:43:a2:fe:1d:d1:31:ae:1e:
        f3:3e:1d:ff:67:42:84:a0:3d:44:57:9c:f3:0f:c3:54:
        dd:6e:4b:3f:f8:d5:ff:a4:1e:77:4b:9d:6f:25:57:c4:
        14:c9:44:40:62:71:03:c0:82:58:fb:cb:a9:84:8a:26:
        93:d7:1a:c9:ba:e7:b0:0c:ee:3f:6a:ae:d0:9b:8e:b6:
        80:3e:8f:ce:07:34:aa:f3:e1:bd:d7:bb:8d:78:99:4e:
        08:c9:f8:0d:aa:87:dc:01:8b:3c:7b:de:32:53:5c:7b:
        b1:53:df:8a:55:04:6c:b4:16:78:05:c6:0b:b1:9c:7d:
        66:2d:67:33:4e:80:84:14:cb:d2:92:27:89:77:c6:9d:
        bd:a2:3d:c0:09:6a:e2:de:2f:1b:64:7c:77:89:24:ca:
        58:77:3a:18:ac:d9:9c:f4:02:94:79:4e:03:17:e2:23:
        bd:0e:58:22:eb:9a:15:ea:b3:22:b5:25:f0:21:e7:4a:
        c3:ee:5a:0f:f9:66:b7:a5:89:3b:f4:6a:07:ae:66:5b:
        fa:df:58:f4:8d:97:20:2f:04:df:ee:34:a3:7a:eb:0b
    Fingerprint (SHA-256):

99:7A:C8:28:07:17:2B:FB:92:74:C0:5B:22:E7:09:FA:F1:2B:A9:7A:C4:01:A1:7C:9A:61:47:F5:45:79:ED:8B
    Fingerprint (SHA1):
        C7:5B:3B:F3:77:63:35:35:32:38:DB:C5:8C:D6:AE:99:0E:40:1D:97

    Certificate Trust Flags:
        SSL Flags:
            Valid CA
            Trusted CA
            User
            Trusted Client CA
        Email Flags:
            Valid CA
            Trusted CA
            User
        Object Signing Flags:
            Valid CA
            Trusted CA
            User


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

iQEcBAEBCAAGBQJT1rRIAAoJEFg7BmJL2iPObVgH/03FI8UyvQN6s0Z1E9O7mSuO
5pPyD5TbbtFZQusnjXJWjzlKRehcBrLVY3pUeaXj2vI/Ar12bHyhMYhrvXm6njeJ
LlWoediIwQhwXPsicsoim3Qn5We/hRKexdEMkbRMuK+qPD0odBc2uR0j+nx3BPQj
YX3OcEWljc2HHtaFfBJDBYSErHc/6028pZ1OD/JMfU5eRifp+S/VW+SqOOzpUgqG
HIcUmXTuEIdM0Dfz50HHmK+6Bt+Xsio/y8BDBFcS8ekVzv/TGHzLJ5nUg1rsks2A
+qt8VKINqEsl+J5wfhd9tHRmm7dr7jAjvZGEDfT0sz1VdGYqnriSEyYoQ2fbonk=
=drpy
-----END PGP SIGNATURE-----




More information about the Freeipa-users mailing list