Bug 695675

The service's design didn't take into account the possibility that it would be asked to resubmit a certificate request while there was no key pair available, so it would get confused.  Changing it to check whether or not it was able to successfully read information about the private key, and going back to the key generation phase if it hadn't, fixes this.  As a prerequisite, it needs to also read that information back immediately after generating a key in order for the key size to be known, which is what it uses as an indicator of the key being present.

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)Create a temp directory

[root@testing ~]# mkdir /tmp/kaleem

(4)Issue a certificate request using directory as NSS database created in last step

[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: NEED_KEY_PAIR
	stuck: no
	key pair storage: type=NSSDB,location='/tmp/kaleem',nickname='test'
	certificate: type=NSSDB,location='/tmp/kaleem',nickname='test'
	CA: SelfSign
	issuer: 
	subject: 
	expires: unknown
	track: yes
	auto-renew: yes
[root@testing ~]#

Request status is 'NEED_KEY_PAIR' here.

(5)Change SELinux security context of temp directory created in step (3)

[root@testing ~]# chcon -t cert_t  /tmp/kaleem/
[root@testing ~]#

(6)Resubmit the certificate request

[root@testing ~]# getcert resubmit -i testing
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=testing.mars.lab.eng.pnq.redhat.com
	subject: CN=testing.mars.lab.eng.pnq.redhat.com
	expires: 20120413015649
	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 ~]#

Now here request status is 'MONITORING'.

Result:

Now certificate is generated after changing the SELinux context of the directory.

    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:
Previously, the getcert tool terminated unexpectedly with a segmentation fault if the user issued the getcert start-tracking command with changed values of the parameters Extended Key Usage, DNS, Email and Principal name. The command caused a buffer overflow in the getcert tool because the internal buffer in the getcert command was too small to hold four new values. This update enlarges the internal buffer of the command and the bug no longer occurs.

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