Bug 695672
Summary: | Subject and Principal name switches are not working in case of 'getcert resubmit' | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Kaleem <ksiddiqu> | ||||
Component: | certmonger | Assignee: | Nalin Dahyabhai <nalin> | ||||
Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.1 | CC: | dpal, jgalipea, kchamart, syeghiay | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | certmonger-0.41-1.el6 | Doc Type: | Bug Fix | ||||
Doc Text: |
Prior to this update, certmonger could have seemingly ignored the attempts to resubmit a certificate with changed Subject and Principal names. This occurred because the certificate changes were not saved if a certificate with the same nickname already existed in the certificate database. With this update, the certmonger utility removes the certificates with the respective nickname before storing the new certificate and the resubmit command works as expected.
|
Story Points: | --- | ||||
Clone Of: | |||||||
: | 695717 (view as bug list) | Environment: | |||||
Last Closed: | 2011-05-19 13:07:25 UTC | Type: | --- | ||||
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: | 695717 | ||||||
Attachments: |
|
Description
Kaleem
2011-04-12 11:35:48 UTC
Created attachment 491461 [details]
certmonger's request file
I expect this is only being seen when we use NSS databases for storage. This happens when the service goes to save the just-acquired certificate to the database, apparently succeeds, and then goes to re-read the certificate from the database to as a consistency measure -- the old certificate is still there, so that's what we cache in the request file. We'd been checking for duplicate-certificate-name errors while importing the new certificate, but apparently we're not getting those any more, but deleting any preexisting certificates from the destination database before attempting to import the new one seems to be a usable workaround. Verified. RHEL Version: ============= [root@testing ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.1 Beta (Santiago) Certmonger Version: =================== [root@testing ~]# rpm -qai certmonger |head Name : certmonger Relocations: (not relocatable) Version : 0.41 Vendor: Red Hat, Inc. Release : 1.el6 Build Date: Tue 12 Apr 2011 03:15:19 AM IST Install Date: Wed 13 Apr 2011 07:21:08 AM IST Build Host: hs20-bc2-4.build.redhat.com Group : System Environment/Daemons Source RPM: certmonger-0.41-1.el6.src.rpm Size : 871428 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://certmonger.fedorahosted.org Summary : Certificate status monitor and PKI enrollment client [root@testing ~]# Steps used to verify: ===================== (1)Install certmonger [root@testing ~]# yum install certmonger -y Installed: certmonger.x86_64 0:0.41-1.el6 Dependency Installed: libtevent.x86_64 0:0.9.8-8.el6 (2)Start certmonger service [root@testing ~]# service certmonger start Starting certmonger: [ OK ] (3)Creating a temp directory [root@testing ~]# mkdir /tmp/kaleem (4)Change SELinux security context of temp directory created in last step [root@testing ~]# chcon -t cert_t /tmp/kaleem/ (5)Issue a certificate request with default subject and principal name [root@testing ~]# getcert request -d /tmp/kaleem/ -n test -I testing -c Selfsign New signing request "testing" added. [root@testing ~]# getcert list Number of certificates and requests being tracked: 1. Request ID 'testing': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/tmp/kaleem',nickname='test',token='NSS Certificate DB' certificate: type=NSSDB,location='/tmp/kaleem',nickname='test',token='NSS Certificate DB' CA: SelfSign issuer: CN=testing.mars.lab.eng.pnq.redhat.com subject: CN=testing.mars.lab.eng.pnq.redhat.com expires: 20120413035214 dns: testing.mars.lab.eng.pnq.redhat.com principal name: host/testing.mars.lab.eng.pnq.redhat.com eku: id-kp-serverAuth track: yes auto-renew: yes [root@testing ~]# Here suject and principal name are default. (6)Resubmitted the request with new subject and principal name [root@testing ~]# getcert resubmit -i testing -N "CN=new.mars.lab.eng.pnq.redhat.com" -K "host/new.mars.lab.eng.pnq.redhat.com" Resubmitting "testing" to "SelfSign". [root@testing ~]# getcert list Number of certificates and requests being tracked: 1. Request ID 'testing': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/tmp/kaleem',nickname='test',token='NSS Certificate DB' certificate: type=NSSDB,location='/tmp/kaleem',nickname='test',token='NSS Certificate DB' CA: SelfSign issuer: CN=new.mars.lab.eng.pnq.redhat.com subject: CN=new.mars.lab.eng.pnq.redhat.com expires: 20120413035541 dns: testing.mars.lab.eng.pnq.redhat.com principal name: host/new.mars.lab.eng.pnq.redhat.com eku: id-kp-serverAuth track: yes auto-renew: yes [root@testing ~]# Result: Now subject and principal names are changed to new provided ones. Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Prior to this update, certmonger could have seemingly ignored the attempts to resubmit a certificate with changed Subject and Principal names. This occurred because the certificate changes were not saved if a certificate with the same nickname already existed in the certificate database. With this update, the certmonger utility removes the certificates with the respective nickname before storing the new certificate and the resubmit command works as expected. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0570.html |