RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 952241 - ipa cert automatic renew: wrong trust argument assigned to renewed certs
Summary: ipa cert automatic renew: wrong trust argument assigned to renewed certs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa
Version: 6.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On: 918335
Blocks: 964130
TreeView+ depends on / blocked
 
Reported: 2013-04-15 13:04 UTC by Martin Kosek
Modified: 2013-11-21 20:53 UTC (History)
6 users (show)

Fixed In Version: ipa-3.0.0-30.el6
Doc Type: Bug Fix
Doc Text:
Cause: When an Identity Management PKI server certificate (auditSigningCert) was being renewed, wrong trust argument were assigned to the renewed cert. Consequence: Identity Management PKI server was unable to use the renewed certificate. Fix: Certificate renewal procedure was updated to assign correct trust arguments to the renewed certificate. Result: Identity Management PKI certificate renewal does not fail.
Clone Of: 918335
Environment:
Last Closed: 2013-11-21 20:53:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Patch fixing the issue (840 bytes, text/plain)
2013-04-22 10:20 UTC, Martin Kosek 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1651 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2013-11-21 00:39:40 UTC

Description Martin Kosek 2013-04-15 13:04:18 UTC 
+++ 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.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) 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.

--- 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.
Comment 1 Martin Kosek 2013-04-22 10:20:31 UTC 
Created attachment 738464 [details]
Patch fixing the issue
Comment 2 Martin Kosek 2013-04-22 10:35:16 UTC 
Moving to POST.
Comment 5 Namita Soman 2013-09-12 12:13:40 UTC 
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
Comment 7 errata-xmlrpc 2013-11-21 20:53:12 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.