[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