Bug 741262 - proper error message not displayed on providing non-existent request with 'getcert resubmit'
Summary: proper error message not displayed on providing non-existent request with 'ge...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: certmonger
Version: 6.2
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-26 12:46 UTC by Kaleem
Modified: 2011-12-06 17:38 UTC (History)
3 users (show)

Fixed In Version: certmonger-0.47-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 17:38:00 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1708 normal SHIPPED_LIVE certmonger bug fix update 2011-12-06 01:02:28 UTC

Description Kaleem 2011-09-26 12:46:01 UTC
Description of problem:
When non-existent request is provided with 'getcert resubmit', proper error message is not displayed and instead help text is displayed.

Version-Release number of selected component (if applicable):
[root@dhcp201-220 ~]# rpm -q certmonger
certmonger-0.46-1.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Install certmonger and start certmonger service.
2.Run 'getcert resubmit' command with non-existent request.

[root@dhcp201-220 getcert_resubmit]# getcert resubmit -i 20110926104229
-E test@redhat.com
None of database directory and nickname or certificate file specified.
getcert - client certificate enrollment tool

Usage: getcert resubmit [options]

Required arguments:
* By request identifier:
  -i NAME	nickname for tracking request
* If using an NSS database for storage:
  -d DIR	NSS database for key and cert
  -n NAME	nickname for NSS-based storage (only valid with -d)
  -t NAME	optional token name for NSS-based storage (only valid with -d)
* If using files for storage:
  -f FILE	PEM file for certificate

* If keys are encrypted:
  -p FILE	file which holds the encryption PIN
  -P PIN	PIN value

* New parameter values for the signing request:
  -N NAME	set requested subject name (default: CN=<hostname>)
  -U EXTUSAGE	set requested extended key usage OID
  -K NAME	set requested principal name
  -D DNSNAME	set requested DNS name
  -E EMAIL	set requested email address

Optional arguments:
* Certificate handling settings:
  -I NAME	new nickname to give to tracking request
  -c CA		use the specified CA rather than the current one
* Bus options:
  -S		connect to the certmonger service on the system bus
  -s		connect to the certmonger service on the session bus
* Other options:
  -v	report all details of errors
[root@dhcp201-220 getcert_resubmit]#

  
Actual results:
Help text as error message is displayed on console.

Expected results:
Following error message should be displayed. 
"No request found that matched arguments."

Comment 2 Dmitri Pal 2011-09-27 01:00:01 UTC
You have not specified an NSS database or file. The message clearly indicates this 

"None of database directory and nickname or certificate file specified."

and then gives help.
The request existence has not been even checked as not all required arguments are provided.

Not a bug.

Comment 3 Jenny Severance 2011-09-27 19:15:43 UTC
from Nalin:

The value passed to -i is an identifier, or nickname of sorts, for the
request.  Most places where you specify a file or directory, getcert
first searches for a matching request to act on; the identifier can be
used to specify it directly.

So, yes, it's a bug, and it can be fixed (pretty easily, I think).

Comment 5 Kaleem 2011-09-29 13:59:59 UTC
Verified.

RHEL Version:
[root@dhcp201-220 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.2 Beta (Santiago)

Certmonger Version:

[root@dhcp201-220 ~]# rpm -q certmonger
certmonger-0.47-1.el6.x86_64

Steps used to verified:
(1)Install Certmonger 

[root@dhcp201-220 ~]# yum install certmonger -y
.
.
  Installing : certmonger-0.47-1.el6.x86_64                                                                                                              1/1 
Installed products updated.
Installed:
  certmonger.x86_64 0:0.47-1.el6                                                                    

(2)Start Certmonger service

[root@dhcp201-220 ~]# service certmonger start
Starting certmonger:                                       [  OK  ]
[root@dhcp201-220 ~]#

(3)Run "getcert resubmit" with a non-existent request identifier

[root@dhcp201-220 ~]# getcert resubmit -i 20110926104229
No request found with specified nickname.
getcert - client certificate enrollment tool

Usage: getcert resubmit [options]

Required arguments:
* By request identifier:
  -i NAME	nickname for tracking request
* If using an NSS database for storage:
  -d DIR	NSS database for key and cert
  -n NAME	nickname for NSS-based storage (only valid with -d)
  -t NAME	optional token name for NSS-based storage (only valid with -d)
* If using files for storage:
  -f FILE	PEM file for certificate

* If keys are encrypted:
  -p FILE	file which holds the encryption PIN
  -P PIN	PIN value

* New parameter values for the signing request:
  -N NAME	set requested subject name (default: CN=<hostname>)
  -U EXTUSAGE	set requested extended key usage OID
  -K NAME	set requested principal name
  -D DNSNAME	set requested DNS name
  -E EMAIL	set requested email address

Optional arguments:
* Certificate handling settings:
  -I NAME	new nickname to give to tracking request
  -c CA		use the specified CA rather than the current one
* Bus options:
  -S		connect to the certmonger service on the system bus
  -s		connect to the certmonger service on the session bus
* Other options:
  -v	report all details of errors
[root@dhcp201-220 ~]#


Result:
Now proper error message "No request found with specified nickname." is displayed on console along with help text.

Comment 6 errata-xmlrpc 2011-12-06 17:38:00 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.

http://rhn.redhat.com/errata/RHBA-2011-1708.html


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