Bug 695672

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