Hide Forgot
+++ This bug was initially created as a clone of Bug #918335 +++ 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 --- Additional comment from Yi Zhang on 2013-03-06 13:13:53 EST --- 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@YZHANG.REDHAT.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. --- Additional comment from Martin Kosek on 2013-03-07 03:53:27 EST --- Upstream ticket: https://fedorahosted.org/freeipa/ticket/3493 --- Additional comment from Yi Zhang on 2013-03-07 09:33:57 EST --- 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 --- Additional comment from Rob Crittenden on 2013-03-07 09:44:51 EST --- 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? --- Additional comment from Yi Zhang on 2013-03-07 11:35:23 EST --- 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@redhat.com) yesterday. And he told me there is no precise way to identify the trust argument with cert serial number. Based on Christina (cfu@redhat.com)'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. --- Additional comment from Rob Crittenden on 2013-03-07 11:42:43 EST --- 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? --- Additional comment from Yi Zhang on 2013-03-07 12:05:59 EST --- [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 --- Additional comment from Yi Zhang on 2013-03-07 12:06:52 EST --- [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 --- Additional comment from Yi Zhang on 2013-03-07 12:19:01 EST --- 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 --- Additional comment from Yi Zhang on 2013-03-07 12:20:38 EST --- one more notes: I didn't do cert renew test after changes backported to certmonger 0.61 --- Additional comment from Nalin Dahyabhai on 2013-03-11 16:30:59 EDT --- (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. --- Additional comment from Martin Kosek on 2013-04-15 08:57:28 EDT --- Created attachment 735887 [details] Patch fixing the issue --- Additional comment from Martin Kosek on 2013-04-15 09:00:13 EDT --- The attached patch is only for reference, this Bugzilla will be fixed when RHEL rebases. Moving to POST.
Created attachment 738464 [details] Patch fixing the issue
Moving to POST.
Verified using ipa-server-3.0.0-35 Pasting snippets from test run: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: wrong trust argument assigned to renewed certs bz964130 6.5 bz 952241 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Uninstalling ipa server for next test (Expected 0, got 0) :: [ PASS ] :: Making sure that /etc/sssd/sssd.conf does not exist. BZ 819982 (Expected 2, got 2) :: [ PASS ] :: Setting to current system time (Expected 0, got 0) :: [ PASS ] :: IPA server install with DNS (Expected 0, got 0) ============ (Trust attributes before renewal) =============== certutil -L -d /var/lib/pki-ca/alias and /etc/httpd/alias/ for each cert Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u ipaCert u,u,u Signing-Cert u,u,u Server-Cert u,u,u ======= report date [Wed Sep 11 20:08:13 EDT 2013] ========= :: [ PASS ] :: stop certmonger service before stop ipa server (Expected 0, got 0) :: [ PASS ] :: stop ipa server Success :: [ PASS ] :: Running 'echo "Current date and time: Wed Sep 11 20:09:14 EDT 2013"' (Expected 0, got 0) Tue Sep 1 00:01:47 EDT 2015 :: [ PASS ] :: Date reset to 1 day before certificate expiry (Expected 0, got 0) New date and time: Tue Sep 1 00:01:47 EDT 2015 :: [ PASS ] :: Running 'echo "New date and time: Tue Sep 1 00:01:47 EDT 2015"' (Expected 0, got 0) :: [ PASS ] :: start ipa server Success Starting certmonger: [ OK ] :: [ PASS ] :: start certmonger service after ipa server started (Expected 0, got 0) :: [ PASS ] :: New Expiry date for Server-Cert (Expected 0, got 0) :: [ PASS ] :: Server-Cert is renewed Not After : Mon Aug 21 04:03:18 2017 :: [ PASS ] :: New Expiry date for auditSigningCert (Expected 0, got 0) :: [ PASS ] :: auditSigningCert is renewed Not After : Mon Aug 21 04:02:18 2017 :: [ PASS ] :: New Expiry date for ocspSigningCert (Expected 0, got 0) :: [ PASS ] :: ocspSigningCert is renewed Not After : Mon Aug 21 04:02:18 2017 :: [ PASS ] :: New Expiry date for subsystemCert (Expected 0, got 0) :: [ PASS ] :: subsystemCert is renewed Not After : Mon Aug 21 04:02:18 2017 :: [ PASS ] :: New Expiry date for ipaCert (Expected 0, got 0) :: [ PASS ] :: ipaCert is renewed Not After : Tue Sep 12 00:07:28 2017 :: [ PASS ] :: New Expiry date for Signing-Cert (Expected 0, got 0) :: [ PASS ] :: Signing-Cert is renewed Not After : Fri Sep 01 04:02:22 2017 :: [ PASS ] :: New Expiry date for Server-Cert (Expected 0, got 0) :: [ PASS ] :: Server-Cert is renewed ============ (Trust attributes after renewal) =============== certutil -L -d /var/lib/pki-ca/alias and /etc/httpd/alias/ for each cert Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u ipaCert u,u,u Signing-Cert u,u,u Server-Cert u,u,u ======= report date [Tue Sep 1 00:05:30 EDT 2015] ========= :: [ PASS ] :: Files /tmp/tmp.64WVaAEBor/before_renewal.txt and /tmp/tmp.64WVaAEBor/after_renewal.txt should not differ :: [ PASS ] :: BZ964130 not found. Trusts attibutes are not changed after renewal
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1651.html