Bug 918335
| Summary: | ipa cert automatic renew: wrong trust argument assigned to renewed certs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Yi Zhang <yzhang> | ||||
| Component: | ipa | Assignee: | Rob Crittenden <rcritten> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | IDM QE LIST <seceng-idm-qe-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.0 | CC: | dpal, emaldona, jgalipea, mkosek, nalin, nsoman | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | ipa-3.2.1-1.el7 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 952241 (view as bug list) | Environment: | |||||
| Last Closed: | 2014-06-13 09:52:04 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 952241 | ||||||
| Attachments: |
|
||||||
the effect of cert errors: 1. ipa cert-show failes [root@grape (RH6.4-x86_64) ipa-autorenewcert] ipa cert-show 15 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) 2. no new cert can be issued by ipa in /var/log/httpd/error_log [Wed Feb 25 09:48:33 2015] [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): Unable to communicate with CMS (Not Found) [Wed Feb 25 09:48:33 2015] [error] ipa: INFO: admin.COM: cert_show(u'15'): CertificateOperationError 3. and of course, ipa cert automatic renew is totally broken. Other than above, the ipa user, group, host commands works fine (tested and passed). I haven't check all ipa commands. But it seems as long ipa command does not touch cert, it works fine. Upstream ticket: https://fedorahosted.org/freeipa/ticket/3493 I have check all other IPA certs, and above two are the only two that has trust arguments changed. my test was performed in both i386 & x86_64 It is very strange that some of the nicknames are duplicated in the certutil output, with different trust flags. Yi can you provide: certutil -L output for the auditSigningCert cert-pki-ca and Server-Cert cert-pki-ca Can you confirm that BEFORE you did any renewal that the Server-Cert cert-pki-ca cert appeared twice in the output? there are two certs share same nickname -- one is expired certs, another is valid certs. I am in a meeting right now. I will post certutil details later. -- However, the certutil -L -d <right dir> -n "auditSigningCert cert-pki-ca" will NOT tell you what trust argument is. I have consulted Elio (emaldona) yesterday. And he told me there is no precise way to identify the trust argument with cert serial number. Based on Christina (cfu)'s comment, (1) if the trust argument changed from "u,u,Pu" to "u,u,u", it lose the peer trust and won't function any more. (2) changes from u,u,u -> u,u,Pu is acceptable -- it won't cause any problem. Although it should not be this way. Another notes from Elio: The trust argument is not coming from the cert it self. A cert is a cert. The trust argument is assigned when it is being imported. Yes, I understand that. That doesn't answer the question why there is different trust on the different certificates. Is this an NSS bug where setting trust when there are multiple certs with the same subject doesn't work or is it something else (such as there being a condition where we don't call certutil to set the trust). The purpose of showing the contents of the certificate is to try to determine if there is some difference in the certificates themselves which may be causing NSS to not set trust correctly. It is unclear how you can reproduce this at will now when it wasn't reproducible before. What changed? [root@grape (RH6.4-x86_64) ipa-autorenewcert] certutil -L -d /var/lib/pki-ca/alias/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
auditSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,Pu
caSigningCert cert-pki-ca CTu,Cu,Cu
auditSigningCert cert-pki-ca u,u,Pu
Server-Cert cert-pki-ca u,u,u
ocspSigningCert cert-pki-ca u,u,Pu
[root@grape (RH6.4-x86_64) ipa-autorenewcert] certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca"
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 14 (0xe)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=YZHANG.REDHAT.COM"
Validity:
Not Before: Mon Feb 23 22:47:20 2015
Not After : Sun Feb 12 22:47:20 2017
Subject: "CN=CA Audit,O=YZHANG.REDHAT.COM"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
f8:71:43:01:c6:6a:97:d8:cb:ce:84:be:e2:27:b6:b7:
d8:f2:12:2a:2b:f7:9c:3e:e9:36:5e:f1:5c:b8:b5:d8:
89:0d:97:63:7d:ad:39:53:31:35:84:d7:35:fd:2b:58:
9c:02:3b:94:be:9a:cc:89:34:ff:01:ab:2e:e5:08:38:
53:7c:30:43:8b:df:82:51:cf:14:c3:9c:46:74:6b:00:
5b:3b:e9:ea:a4:79:36:6f:ee:8f:3a:43:ed:ea:0b:7a:
9e:c3:00:7d:a2:c1:f8:91:0e:c5:d5:49:80:0b:95:56:
fb:8a:f2:01:bd:74:8e:af:69:46:32:76:8a:a7:67:89:
36:24:07:b9:6a:cf:5c:93:11:58:03:24:83:96:c7:6b:
cc:d3:80:a5:12:99:d2:18:c2:5a:51:55:f5:82:84:63:
70:bd:bd:80:40:01:4b:13:28:fe:76:fc:c9:b2:82:f5:
c3:3e:48:5a:f4:14:d3:fd:e1:e1:4b:e8:f3:38:95:43:
66:ca:cb:e4:c4:2f:d5:11:58:34:e5:a2:0b:99:4e:3b:
5a:4f:3e:18:38:18:cc:40:3e:60:d2:6b:12:55:bd:a5:
7f:8c:0a:44:4f:17:8a:cd:02:e8:48:f0:1d:d2:09:80:
de:07:a4:a9:bc:c4:2b:3a:7b:d5:03:03:af:56:f3:ef
Exponent: 65537 (0x10001)
Signed Extensions:
Name: Certificate Authority Key Identifier
Key ID:
2d:63:7d:9a:a6:c8:90:2f:99:1d:dc:d4:e7:71:ba:15:
e9:c3:a0:45
Name: Certificate Subject Key ID
Data:
43:43:a3:f3:bf:d3:01:6a:ea:63:d0:8c:4e:43:df:a2:
5c:43:74:b9
Name: Certificate Key Usage
Critical: True
Usages: Digital Signature
Non-Repudiation
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Signature:
47:05:fb:a7:a4:6c:57:88:02:fb:4f:a3:0f:2a:cf:92:
76:ad:30:3b:8a:26:b7:02:f3:78:b9:60:d8:60:65:ab:
03:dd:6d:60:da:7b:6a:db:02:03:ea:93:25:f1:18:e9:
6f:b0:9e:9e:93:80:92:6a:00:49:34:87:ec:2a:19:51:
df:2f:f5:f5:93:29:5c:8e:61:51:4e:62:42:07:ce:ee:
22:ed:1a:81:fc:e6:68:b9:80:cf:7e:27:42:20:20:45:
e8:a7:17:13:39:03:36:c5:4f:5c:89:f6:e5:13:4b:ad:
98:b0:1e:8f:48:df:e8:7e:42:06:79:68:61:49:d7:fe:
55:ff:0f:50:c4:b7:83:5c:dc:3e:62:17:14:82:f5:a3:
a5:17:c1:d5:c7:98:09:25:de:37:e9:4b:bc:3c:5a:50:
4a:fd:3d:cf:27:95:99:5a:40:be:13:48:e4:0a:14:36:
e5:2a:5b:1e:da:1c:c3:e7:12:f5:07:a6:0d:98:f6:51:
aa:05:b0:73:5e:96:af:9f:32:69:83:3b:48:ab:8c:e6:
62:8b:7f:5b:9f:70:b8:e0:ee:12:45:cd:62:66:09:86:
ed:ea:27:3e:50:9b:a3:41:a4:91:3b:f6:5d:c2:54:e6:
c6:42:91:2d:69:02:b3:9c:e5:5d:1c:f5:65:04:ea:86
Fingerprint (MD5):
5E:61:F5:12:1C:5A:F3:A6:CD:C9:91:2D:AE:54:EE:03
Fingerprint (SHA1):
42:03:CA:D0:26:31:81:50:BA:E0:8C:48:FC:8C:06:B4:89:DF:AD:4E
Certificate Trust Flags:
SSL Flags:
User
Email Flags:
User
Object Signing Flags:
User
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=YZHANG.REDHAT.COM"
Validity:
Not Before: Tue Mar 05 23:30:59 2013
Not After : Mon Feb 23 23:30:59 2015
Subject: "CN=CA Audit,O=YZHANG.REDHAT.COM"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
f8:71:43:01:c6:6a:97:d8:cb:ce:84:be:e2:27:b6:b7:
d8:f2:12:2a:2b:f7:9c:3e:e9:36:5e:f1:5c:b8:b5:d8:
89:0d:97:63:7d:ad:39:53:31:35:84:d7:35:fd:2b:58:
9c:02:3b:94:be:9a:cc:89:34:ff:01:ab:2e:e5:08:38:
53:7c:30:43:8b:df:82:51:cf:14:c3:9c:46:74:6b:00:
5b:3b:e9:ea:a4:79:36:6f:ee:8f:3a:43:ed:ea:0b:7a:
9e:c3:00:7d:a2:c1:f8:91:0e:c5:d5:49:80:0b:95:56:
fb:8a:f2:01:bd:74:8e:af:69:46:32:76:8a:a7:67:89:
36:24:07:b9:6a:cf:5c:93:11:58:03:24:83:96:c7:6b:
cc:d3:80:a5:12:99:d2:18:c2:5a:51:55:f5:82:84:63:
70:bd:bd:80:40:01:4b:13:28:fe:76:fc:c9:b2:82:f5:
c3:3e:48:5a:f4:14:d3:fd:e1:e1:4b:e8:f3:38:95:43:
66:ca:cb:e4:c4:2f:d5:11:58:34:e5:a2:0b:99:4e:3b:
5a:4f:3e:18:38:18:cc:40:3e:60:d2:6b:12:55:bd:a5:
7f:8c:0a:44:4f:17:8a:cd:02:e8:48:f0:1d:d2:09:80:
de:07:a4:a9:bc:c4:2b:3a:7b:d5:03:03:af:56:f3:ef
Exponent: 65537 (0x10001)
Signed Extensions:
Name: Certificate Authority Key Identifier
Key ID:
2d:63:7d:9a:a6:c8:90:2f:99:1d:dc:d4:e7:71:ba:15:
e9:c3:a0:45
Name: Certificate Key Usage
Critical: True
Usages: Digital Signature
Non-Repudiation
Name: Authority Information Access
Method: PKIX Online Certificate Status Protocol
Location:
URI: "http://grape.yzhang.redhat.com:80/ca/ocsp"
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Signature:
34:04:77:8f:17:f4:a5:6e:10:3d:51:e2:7a:11:78:db:
44:81:c3:31:21:2c:15:d7:7d:f2:f5:a5:40:f1:7d:0a:
80:40:6c:77:39:6b:89:bf:74:f3:4e:31:91:81:ab:ca:
f0:4e:ce:4c:08:37:b8:a5:05:19:7e:4a:5d:46:db:8c:
c3:16:34:6e:88:b8:ae:85:0b:04:b5:b7:95:6a:ef:6c:
ae:fc:8a:10:f6:de:b6:de:05:1f:01:7c:b5:49:fa:63:
b4:b5:04:6c:18:96:37:8d:13:ee:68:c5:e6:d3:70:ec:
4e:a0:57:f2:87:0e:2c:c6:46:21:81:3f:b4:9f:74:3a:
0d:27:b1:04:0d:7a:99:99:be:12:a4:fe:13:93:1b:b1:
40:c6:cc:68:c7:fe:0a:80:27:bb:bf:2e:dc:16:11:2b:
08:5a:30:83:3e:ca:73:41:46:8b:d1:90:bd:69:9f:4f:
d9:51:35:a8:91:a1:19:a0:aa:47:8b:36:b5:e8:6e:d7:
16:5f:cd:1a:c9:b0:9e:a4:ec:42:ef:a8:a3:7f:d6:b7:
e0:34:bd:1a:50:ab:ca:26:66:a9:bd:7e:ab:dd:56:31:
28:15:ae:59:32:8e:19:3d:99:f6:bc:ef:6e:13:8d:62:
fa:7b:5f:97:14:6d:4a:f6:b9:ec:38:bb:42:7e:a9:d8
Fingerprint (MD5):
2B:E3:C1:AF:0D:2A:9B:C4:51:94:B4:5D:67:23:1C:44
Fingerprint (SHA1):
72:B8:D5:46:62:C5:CE:3A:D0:EC:A1:09:E6:C0:3C:E1:EB:28:01:AC
Certificate Trust Flags:
SSL Flags:
User
Email Flags:
User
Object Signing Flags:
Terminal Record
Trusted
User
[root@grape (RH6.4-x86_64) ipa-autorenewcert] certutil -L -d /var/lib/pki-ca/alias/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
auditSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,Pu
caSigningCert cert-pki-ca CTu,Cu,Cu
auditSigningCert cert-pki-ca u,u,Pu
Server-Cert cert-pki-ca u,u,u
ocspSigningCert cert-pki-ca u,u,Pu
[root@grape (RH6.4-x86_64) ipa-autorenewcert] certutil -L -d /var/lib/pki-ca/alias/ -n "subsystemCert cert-pki-ca"
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 16 (0x10)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=YZHANG.REDHAT.COM"
Validity:
Not Before: Mon Feb 23 22:46:20 2015
Not After : Sun Feb 12 22:46:20 2017
Subject: "CN=CA Subsystem,O=YZHANG.REDHAT.COM"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
e2:db:76:73:d7:cf:33:ec:bf:3f:70:18:d1:ad:ab:fb:
54:68:16:dc:29:ea:f1:38:c2:45:9f:17:d0:e4:1b:f4:
9e:36:bf:82:cd:cc:ef:34:d9:37:67:02:00:d7:af:98:
ce:11:54:c1:f0:33:f7:ec:ba:7d:63:bd:e1:4e:f1:86:
20:da:0e:e7:fa:d3:24:2c:b7:08:ac:f1:2c:aa:7c:6f:
71:1c:74:70:56:14:ed:13:87:3b:0a:51:2c:10:c9:ff:
06:97:52:4b:80:b3:4c:a8:f1:dc:01:d3:41:c2:69:87:
e3:4f:68:25:9e:6a:17:ee:d8:5f:61:7c:4d:76:14:ef:
6e:84:bc:9c:03:b3:4f:fa:5b:d1:5f:8d:44:8a:ae:52:
7b:4e:a4:5f:ac:3d:e5:fb:60:1f:15:f9:45:b6:0f:c8:
93:fc:8b:39:cb:67:f3:84:83:a5:1a:dd:f4:ad:d0:83:
f1:40:77:16:6d:b1:ab:e9:46:6c:20:4f:24:e0:9a:6e:
de:f5:d8:a9:6c:e9:e0:16:3b:f9:c0:0f:f8:ad:da:63:
1a:ac:ba:b9:8d:e6:66:30:e3:59:82:12:e1:21:2d:e2:
18:d9:2d:da:c9:da:2c:57:7c:28:7d:fa:43:a9:63:a6:
fe:c7:41:15:6c:16:fe:bd:22:03:c5:b6:28:bc:dc:41
Exponent: 65537 (0x10001)
Signed Extensions:
Name: Certificate Authority Key Identifier
Key ID:
2d:63:7d:9a:a6:c8:90:2f:99:1d:dc:d4:e7:71:ba:15:
e9:c3:a0:45
Name: Authority Information Access
Method: PKIX Online Certificate Status Protocol
Location:
URI: "http://grape.yzhang.redhat.com:80/ca/ocsp"
Name: Certificate Key Usage
Critical: True
Usages: Digital Signature
Non-Repudiation
Key Encipherment
Data Encipherment
Name: Extended Key Usage
TLS Web Server Authentication Certificate
TLS Web Client Authentication Certificate
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Signature:
2c:83:a1:fe:2c:e3:5b:6e:97:a1:e3:da:54:f2:be:ab:
70:84:4b:bf:52:50:dc:e4:e8:43:1e:59:ce:3b:4e:f0:
13:4d:52:4e:90:6f:bb:78:78:13:6d:e8:13:81:1a:bb:
32:a1:1d:72:02:75:27:77:47:49:bd:e9:78:36:f2:99:
df:bf:67:10:2a:24:98:f1:28:2f:bf:26:01:ac:1b:10:
ef:ab:a6:3a:29:a4:95:74:42:7c:2c:69:4b:1b:a9:c3:
df:23:07:5f:1d:6c:46:4a:53:ed:9c:d2:41:ec:46:8b:
5d:9c:22:99:6c:01:09:59:c2:ee:29:f2:87:30:e6:79:
6b:fb:2d:be:bd:39:85:46:c1:38:82:5f:f6:ee:8e:d0:
1d:f4:89:bb:49:8a:ce:17:f7:05:8d:14:e7:a7:1a:a5:
ca:07:26:33:43:60:4e:23:b2:72:b5:83:f9:c8:e1:79:
46:3a:57:db:fa:f9:b3:30:3a:72:6e:31:bb:c2:b8:d0:
67:a4:f7:a4:35:56:bd:7d:2b:b8:ed:df:90:aa:52:e1:
32:13:be:42:26:f8:0c:82:5f:d2:49:e2:9d:7f:d9:8e:
ea:89:19:34:1e:f9:34:46:0d:e8:a2:57:23:7b:f3:47:
87:92:7c:34:a3:f4:a4:57:c0:12:8b:71:2c:be:cc:14
Fingerprint (MD5):
44:21:56:85:96:68:35:35:6C:6F:82:02:D9:AF:FB:60
Fingerprint (SHA1):
1D:97:93:BB:B4:58:7C:A5:48:62:A6:0E:6C:CD:D8:B9:20:23:D6:1E
Certificate Trust Flags:
SSL Flags:
User
Email Flags:
User
Object Signing Flags:
Terminal Record
Trusted
User
the one that tested is certmonger 0.65 the one that released in RHEL6.4 is actuall 0.61 please refer to this bug https://bugzilla.redhat.com/show_bug.cgi?id=883484 one more notes: I didn't do cert renew test after changes backported to certmonger 0.61 (In reply to comment #4) > It is very strange that some of the nicknames are duplicated in the certutil > output, with different trust flags. certmonger previously didn't prune out certificates that shared the same subject name and nickname as a new certificate being added, as they're not considered to be conflicts. But it appears that certutil only tweaks the trust settings for one of the certificates with the given nickname when it's told to, and if the one it modifies is not the new one, then this would be the result. Yi, can you repeat this with a certmonger nightly from 20130306T2312Z or later? It does two things differently when storing a certificate to a database: 1. If there's a certificate already present with the same subject and nickname, that certificate's trust is applied to the new certificate. 2. In addition to removing certificates with the same subject name but different nickname, and certificates with the same nickname but different subjects, after saving a new certificate, any others present with the same nickname and subject will also be removed. Created attachment 735887 [details]
Patch fixing the issue
The attached patch is only for reference, this Bugzilla will be fixed when RHEL rebases. Moving to POST. verified on RHEL7.0 beta bits
before automatic renew: (original ipa certs)
[root] certutil -L -d /var/lib/pki/pki-tomcat/alias/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
ocspSigningCert cert-pki-ca u,u,u
subsystemCert 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
after automatic renew: (renewed ipa certs)
[root] certutil -L -d /var/lib/pki/pki-tomcat/alias/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u
ocspSigningCert cert-pki-ca u,u,u
caSigningCert cert-pki-ca CTu,Cu,Cu
subsystemCert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
===================== rpms =================
[yi@rh7a (RH7.0-x86_64) ~] rpm -qa | grep "sss\|ipa"
sssd-ad-1.11.2-1.el7.x86_64
sssd-client-1.11.2-1.el7.x86_64
python-iniparse-0.4-8.el7.noarch
sssd-krb5-common-1.11.2-1.el7.x86_64
libipa_hbac-1.11.2-1.el7.x86_64
python-sssdconfig-1.11.2-1.el7.noarch
sssd-common-1.11.2-1.el7.x86_64
sssd-1.11.2-1.el7.x86_64
sssd-ldap-1.11.2-1.el7.x86_64
ipa-server-3.3.3-3.el7.x86_64
device-mapper-multipath-libs-0.4.9-58.el7.x86_64
libsss_idmap-1.11.2-1.el7.x86_64
libipa_hbac-python-1.11.2-1.el7.x86_64
sssd-common-pac-1.11.2-1.el7.x86_64
ipa-admintools-3.3.3-3.el7.x86_64
libsss_nss_idmap-1.11.2-1.el7.x86_64
sssd-proxy-1.11.2-1.el7.x86_64
ipa-python-3.3.3-3.el7.x86_64
ipa-client-3.3.3-3.el7.x86_64
device-mapper-multipath-0.4.9-58.el7.x86_64
sssd-krb5-1.11.2-1.el7.x86_64
sssd-ipa-1.11.2-1.el7.x86_64
[yi@rh7a (RH7.0-x86_64) ~] uname -a
Linux rh7a.yzhang.redhat.com 3.10.0-48.el7.x86_64 #1 SMP Fri Nov 8 10:11:01 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |
Description of problem: When a cert being renewed, wrong trust argument being assigned to renewed certs Version-Release number of selected component (if applicable): [root@apple (RH6.4-i386) ipa-autorenewcert] rpm -qa | grep ipa-server ipa-server-selinux-3.0.0-25.el6.i686 ipa-server-3.0.0-25.el6.i686 [root@apple (RH6.4-i386) ipa-autorenewcert] rpm -qa | grep certmonger certmonger-0.61-3.el6.i686 How reproducible: always Steps to Reproduce: 1. install ipa server 2. check trust arguments use "certutil -L -d /var/lib/pki-ca/alias" 3. adjust system time to trigger automatic renew 4. check trust arguments again with same command here is what I have: ============== before auto renew ============== [root@apple (RH6.4-i386) alias] certutil -L -d . Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI subsystemCert cert-pki-ca u,u,u Server-Cert 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 ocspSigningCert cert-pki-ca u,u,Pu ============== after auto renew ================== [root@apple (RH6.4-i386) alias] certutil -L -d . Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,Pu caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,Pu Additional info: summary: auditSigningCert cert-pki-ca u,u,Pu -> u,u,u subsystemCert cert-pki-ca u,u,u -> u,u,Pu I haven't check the other ipa certs yet. I will post my finding here as comment