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 695672 - Subject and Principal name switches are not working in case of 'getcert resubmit'
Summary: Subject and Principal name switches are not working in case of 'getcert resub...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: certmonger
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 695717
TreeView+ depends on / blocked
 
Reported: 2011-04-12 11:35 UTC by Kaleem
Modified: 2011-05-19 13:07 UTC (History)
4 users (show)

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.
Clone Of:
: 695717 (view as bug list)
Environment:
Last Closed: 2011-05-19 13:07:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
certmonger's request file (4.14 KB, text/plain)
2011-04-12 11:37 UTC, Kaleem
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0570 0 normal SHIPPED_LIVE certmonger bug fix and enhancement update 2011-05-19 09:37:40 UTC

Description Kaleem 2011-04-12 11:35:48 UTC
Description of problem:
Subject (-N) and Principal (-K) name switches are not working in case of 'getcert resubmit'.


Version-Release number of selected component (if applicable):
certmonger-0.40-1.el6.x86_64

How reproducible:
Issue a certificate request and resubmit its request with Subject and Principal name

Steps to Reproduce:
(1)issue a request with default(hostname) Subject and Principal name

   [root@dhcp193-17 getcert_resubmit]# getcert request -d /tmp/kaleem/ -n test -c Selfsign
New signing request "20110407131653" added.
[root@dhcp193-17 getcert_resubmit]# getcert list
Number of certificates and requests being tracked: 1.
Request ID '20110407131653':
    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=dhcp193-17.pnq.redhat.com
    subject: CN=dhcp193-17.pnq.redhat.com
    expires: 20120407130339
    dns: dhcp193-17.pnq.redhat.com
    principal name: host/dhcp193-17.pnq.redhat.com
    eku: id-kp-serverAuth
    track: yes
    auto-renew: yes
[root@dhcp193-17 getcert_resubmit]#

   Hers subject is CN=dhcp193-17.pnq.redhat.com which is actually the hostname.

(2)Resubmitting the request with different Subject and Principal name

[root@dhcp193-17 getcert_resubmit]# getcert resubmit -i 20110407131653 -N "CN=testing.lab.eng.pnq.redhat.com" -K "host/testing.lab.eng.pnq.redhat.com"
Resubmitting "20110407131653" to "SelfSign".
[root@dhcp193-17 getcert_resubmit]# getcert list
Number of certificates and requests being tracked: 1.
Request ID '20110407131653':
    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=dhcp193-17.pnq.redhat.com
    subject: CN=dhcp193-17.pnq.redhat.com
    expires: 20120407130339
    dns: dhcp193-17.pnq.redhat.com
    principal name: host/dhcp193-17.pnq.redhat.com
    eku: id-kp-serverAuth
    track: yes
    auto-renew: yes
[root@dhcp193-17 getcert_resubmit]#

  
Actual results:
Subject name of the request is "CN=dhcp193-17.pnq.redhat.com" which is supposed to be testing.lab.eng.pnq.redhat.com.

Expected results:
Subject name of the request should have been changed to "CN=testing.lab.eng.pnq.redhat.com" and Principal name to "host/testing.lab.eng.pnq.redhat.com"


Additional info:
(1)In /var/lib/certmonger/requests/20110407131653, these are shown in template_subject and template_principal fields

template_subject=CN=testing.lab.eng.pnq.redhat.com
template_hostname=dhcp193-17.pnq.redhat.com
template_principal=host/testing.lab.eng.pnq.redhat.com

(2)Certmonger's request file has been attached for reference.

Comment 1 Kaleem 2011-04-12 11:37:06 UTC
Created attachment 491461 [details]
certmonger's request file

Comment 3 Nalin Dahyabhai 2011-04-12 13:04:38 UTC
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.

Comment 7 Kaleem 2011-04-13 09:36:17 UTC
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.

Comment 8 Eva Kopalova 2011-05-02 17:04:40 UTC
    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.

Comment 9 errata-xmlrpc 2011-05-19 13:07:25 UTC
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


Note You need to log in before you can comment on or make changes to this bug.