Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1163498

Summary: Renewing the CA signing certificate does not extend its validity period end
Product: Red Hat Enterprise Linux 7 Reporter: Scott Poore <spoore>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: urgent    
Version: 7.1CC: aakkiang, alee, cfu, jcholast, jgalipea, mkosek, nkinder, rcritten
Target Milestone: rcKeywords: TestBlocker
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.1.0-7.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1150031 Environment:
Last Closed: 2015-03-05 10:14:37 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: 1150031, 1165155    
Bug Blocks: 886645, 1153289    

Comment 1 Scott Poore 2014-11-12 20:52:07 UTC 
Cloned the original bug here and adding the notes/output from what I saw for the same thing:

[root@rhel71-1 ~]# date
Thu Nov  2 00:50:50 CDT 2034

[root@rhel71-1 ~]# ipa-certupdate
trying https://rhel71-1.example.com/ipa/json
Forwarding 'ca_is_enabled' to json server 'https://rhel71-1.example.com/ipa/json'
Systemwide CA database updated.
Added the CA to the systemwide CA trust database.
The ipa-certupdate command was successful

Checking that all certs are good:

[root@rhel71-1 ~]# getcert list | egrep "status|expires"
        status: MONITORING
        expires: 2034-11-05 20:44:23 UTC
        status: MONITORING
        expires: 2034-11-05 20:44:23 UTC
        status: MONITORING
        expires: 2034-11-05 20:44:23 UTC
        status: MONITORING
        expires: 2034-11-05 20:44:23 UTC
        status: MONITORING
        expires: 2034-11-05 20:44:23 UTC
        status: MONITORING
        expires: 2034-11-05 20:44:23 UTC
        status: MONITORING
        expires: 2034-11-05 20:44:23 UTC
        status: MONITORING
        expires: 2034-11-05 20:44:23 UTC

Looking for the CA:

[root@rhel71-1 ~]# certutil -d /etc/ipa/nssdb -L -n "EXAMPLE.COM IPA CA" | \
>     egrep "Serial Number: |Not After Subject:"
        Serial Number: 115 (0x73)
            Not After : Sun Nov 05 20:44:23 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
        Serial Number: 1 (0x1)
            Not After : Sun Nov 05 20:44:23 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"

[root@rhel71-1 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 \
>     -b cn=certificates,cn=ipa,cn=etc,dc=example,dc=com | \
>     egrep "ipaCertIssuerSerialipaCertSubject^cn^dn:"
dn: cn=certificates,cn=ipa,cn=etc,dc=example,dc=com
cn: certificates
dn: cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com
cn: EXAMPLE.COM IPA CA
ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.COM;1
ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.COM;115
ipaCertSubject: CN=Certificate Authority,O=EXAMPLE.COM
Comment 3 Jan Cholasta 2014-11-13 08:24:03 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4717
Comment 4 Scott Poore 2014-11-14 15:50:23 UTC 
FYI, the above results were from IPA's automatic renewal but, I see the same results with manual renewal:

[root@rhel71-1 ~]# ipa-cacert-manage renew -p Secret123
Renewing CA certificate, please wait
CA certificate successfully renewed
The ipa-cacert-manage command was successful

[root@rhel71-1 ~]# certutil -d /etc/ipa/nssdb -L -n "EXAMPLE.COM IPA CA" | \
>     egrep "Serial Number: |Not After :|Subject:"
        Serial Number: 115 (0x73)
            Not After : Sun Nov 05 20:44:23 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
        Serial Number: 1 (0x1)
            Not After : Sun Nov 05 20:44:23 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"

[root@rhel71-1 ~]# ipa-certupdate 
trying https://rhel71-1.example.com/ipa/session/json
Forwarding 'ca_is_enabled' to json server 'https://rhel71-1.example.com/ipa/session/json'
Systemwide CA database updated.
Added the CA to the systemwide CA trust database.
The ipa-certupdate command was successful

[root@rhel71-1 ~]# certutil -d /etc/ipa/nssdb -L -n "EXAMPLE.COM IPA CA" | \
>     egrep "Serial Number: |Not After :|Subject:"
        Serial Number: 124 (0x7c)
            Not After : Sun Nov 05 20:44:23 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
        Serial Number: 115 (0x73)
            Not After : Sun Nov 05 20:44:23 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
        Serial Number: 1 (0x1)
            Not After : Sun Nov 05 20:44:23 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"

So it seems like the cert from IPA's manual renewal with ipa-cacert-manage also has the same issue with the date.
Comment 6 Scott Poore 2014-11-18 16:07:26 UTC 
FYI, just a little more info and another test trying to manually renew with ipa-cacert-manage:

########## checking date and expirations:

[root@rhel7-3 ~]# date
Thu Jun  8 20:58:07 CDT 2034

[root@rhel7-3 ~]# getcert list | egrep "status|expires|Request|subject"
Request ID '20141118134354':
	status: MONITORING
	subject: CN=CA Audit,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134355':
	status: MONITORING
	subject: CN=OCSP Subsystem,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134356':
	status: MONITORING
	subject: CN=CA Subsystem,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134357':
	status: MONITORING
	subject: CN=Certificate Authority,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134358':
	status: MONITORING
	subject: CN=IPA RA,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134359':
	status: MONITORING
	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134400':
	status: MONITORING
	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134440':
	status: MONITORING
	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC

[root@rhel7-3 ~]# certutil -d /etc/ipa/nssdb -L -n "EXAMPLE.COM IPA CA" | \
>     egrep "Serial Number: |Not After :|Subject:"
        Serial Number: 1 (0x1)
            Not After : Sat Nov 18 13:43:15 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"

[root@rhel7-3 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 \
>     -b cn=certificates,cn=ipa,cn=etc,dc=example,dc=com | \
>     egrep "ipaCertIssuerSerial:|ipaCertSubject:|^cn:|^dn:"
dn: cn=certificates,cn=ipa,cn=etc,dc=example,dc=com
cn: certificates
dn: cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com
cn: EXAMPLE.COM IPA CA
ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.COM;1
ipaCertSubject: CN=Certificate Authority,O=EXAMPLE.COM


########### Now renew:


[root@rhel7-3 ~]# ipa-cacert-manage renew -p Secret123
Renewing CA certificate, please wait
CA certificate successfully renewed
The ipa-cacert-manage command was successful

############ update client side:

[root@rhel7-3 ~]# ipa-certupdate 
trying https://rhel7-3.example.com/ipa/json
Forwarding 'ca_is_enabled' to json server 'https://rhel7-3.example.com/ipa/json'
Systemwide CA database updated.
Systemwide CA database updated.
The ipa-certupdate command was successful

############ Checking expirations:

[root@rhel7-3 ~]# certutil -d /etc/ipa/nssdb -L -n "EXAMPLE.COM IPA CA" | \
>     egrep "Serial Number: |Not After :|Subject:"
        Serial Number: 91 (0x5b)
            Not After : Sat Nov 18 13:43:15 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
        Serial Number: 1 (0x1)
            Not After : Sat Nov 18 13:43:15 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.COM"

[root@rhel7-3 ~]# getcert list | egrep "status|expires|Request|subject"
Request ID '20141118134354':
	status: MONITORING
	subject: CN=CA Audit,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134355':
	status: MONITORING
	subject: CN=OCSP Subsystem,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134356':
	status: MONITORING
	subject: CN=CA Subsystem,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134357':
	status: MONITORING
	subject: CN=Certificate Authority,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134358':
	status: MONITORING
	subject: CN=IPA RA,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134359':
	status: MONITORING
	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134400':
	status: MONITORING
	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC
Request ID '20141118134440':
	status: MONITORING
	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
	expires: 2034-11-18 13:43:15 UTC

So, it doesn't appear to extend the expiration past original even on fresh install and ipa manual renew.
Comment 8 Jan Cholasta 2014-11-19 14:27:14 UTC 
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/52b141ca6a257b8f12d9ad2ade812ec1bfebf0d7
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/7aa855a37b1996588d7d2084176e38145b1587be
Comment 10 Scott Poore 2014-11-21 18:14:31 UTC 
Verified.

Version ::

ipa-server-4.1.0-7.el7.x86_64
certmonger-0.75.14-2.el7.x86_64

Results ::

I walked the time forward to 2034 expiration time within 5 days of expiration.

[root@vm3 log]# ipa-cacert-manage renew
Renewing CA certificate, please wait
CA certificate successfully renewed
The ipa-cacert-manage command was successful


[root@vm3 log]# getcert list | egrep "status|expires|Request|subject"
Request ID '20141121160316':
	status: MONITORING
	subject: CN=CA Audit,O=EXAMPLE.TEST
	expires: 2034-11-21 16:02:41 UTC
Request ID '20141121160317':
	status: MONITORING
	subject: CN=OCSP Subsystem,O=EXAMPLE.TEST
	expires: 2034-11-21 16:02:41 UTC
Request ID '20141121160318':
	status: MONITORING
	subject: CN=CA Subsystem,O=EXAMPLE.TEST
	expires: 2034-11-21 16:02:41 UTC
Request ID '20141121160319':
	status: MONITORING
	subject: CN=Certificate Authority,O=EXAMPLE.TEST
	expires: 2054-11-16 22:26:24 UTC
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Request ID '20141121160320':
	status: MONITORING
	subject: CN=IPA RA,O=EXAMPLE.TEST
	expires: 2034-11-21 16:02:41 UTC
Request ID '20141121160321':
	status: MONITORING
	subject: CN=vm3.example.test,O=EXAMPLE.TEST
	expires: 2034-11-21 16:02:41 UTC
Request ID '20141121160322':
	status: MONITORING
	subject: CN=vm3.example.test,O=EXAMPLE.TEST
	expires: 2034-11-21 16:02:41 UTC
Request ID '20141121160347':
	status: MONITORING
	subject: CN=vm3.example.test,O=EXAMPLE.TEST
	expires: 2034-11-21 16:02:41 UTC

See 20141121160319 above. Date has been extended beyond the 2034 expiration it originally had.  

[root@vm3 log]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 \
>     -b cn=certificates,cn=ipa,cn=etc,dc=example,dc=test | \
>     egrep "ipaCertIssuerSerial:|ipaCertSubject:|^cn:|^dn:"
dn: cn=certificates,cn=ipa,cn=etc,dc=example,dc=test
cn: certificates
dn: cn=EXAMPLE.TEST IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=test
cn: EXAMPLE.TEST IPA CA
ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.TEST;1
ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.TEST;100
ipaCertSubject: CN=Certificate Authority,O=EXAMPLE.TEST

[root@vm3 log]# certutil -d /etc/ipa/nssdb -L -n "EXAMPLE.TEST IPA CA" | \
>     egrep "Serial Number: |Not After :|Subject:"
        Serial Number: 1 (0x1)
            Not After : Tue Nov 21 16:02:41 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.TEST"

[root@vm3 log]# ipa-certupdate 
trying https://vm3.example.test/ipa/json
Forwarding 'ca_is_enabled' to json server 'https://vm3.example.test/ipa/json'
Systemwide CA database updated.
Systemwide CA database updated.
The ipa-certupdate command was successful

[root@vm3 log]# certutil -d /etc/ipa/nssdb -L -n "EXAMPLE.TEST IPA CA" | \
>     egrep "Serial Number: |Not After :|Subject:"
        Serial Number: 100 (0x64)
            Not After : Mon Nov 16 22:26:24 2054
        Subject: "CN=Certificate Authority,O=EXAMPLE.TEST"
        Serial Number: 1 (0x1)
            Not After : Tue Nov 21 16:02:41 2034
        Subject: "CN=Certificate Authority,O=EXAMPLE.TEST"


Now I can see the date pushed out to 2054 as expected.
Comment 12 errata-xmlrpc 2015-03-05 10:14:37 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.

https://rhn.redhat.com/errata/RHSA-2015-0442.html