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 1395509 - certutil -V ignores -f parameter
Summary: certutil -V ignores -f parameter
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.3
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: nss-nspr-maint
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-16 04:23 UTC by Endi Sukma Dewata
Modified: 2019-10-29 19:28 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-11 15:39:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Endi Sukma Dewata 2016-11-16 04:23:59 UTC 
The certutil -V command is supposed to validate a certificate in the NSS database. If the certificate is stored in the internal token the command does not require a password. However, if the certificate is stored in HSM the HSM password needs to be specified. The problem is the command ignores the password specified with the -f parameter, so the password has to be typed in manually which makes automation difficult. This problem may affect future RHCS development.

Steps to reproduce:

1. Create an NSS database and add an HSM module.
2. Store the HSM password in hsm.txt.
3. Add an existing certificate into the HSM (see also bug #1393668):

 $ certutil -A -d nssdb -h hsm -f hsm.txt -n example -i example.crt -t ""

4. Validate the certificate in HSM:

 $ certutil -V -d nssdb -f hsm.txt -n "hsm:example" -u L
 Enter Password or Pin for "hsm":

Actual result: In step #4 the command prompts for the HSM password although the password file is already specified with the -f parameter.

Expected result: The command in step #4 should not prompt for the password since it's already specified with the -f parameter.
Comment 5 Kai Engert (:kaie) (inactive account) 2017-09-01 11:41:56 UTC 
Endi, could you please retest?

And if you retest, could you also please provide information where it's stuck prompting?

You could create a backtrace, that would help us, by doing the following:

- install the nss*/nspr debuginfo packages
- run your test
- once certutil is stuck prompting, attach using gdb
  (use "ps" to find the process ID, then run
     gdb certutil process-id )
- if attaching worked, use
    bt
  to create the stack where it's stuck, and please attach that stack to
  this bug as a text file

thanks
Comment 8 Endi Sukma Dewata 2017-10-30 19:46:19 UTC 
The problem can still be reproduced with nss-3.33 on Fedora 26 (I don't have a RHEL HSM client at the moment).

Here is the backtrace:

(gdb) bt
#0  0x00007f4437e111b0 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f4437d91198 in _IO_new_file_underflow (fp=0x20574f0) at fileops.c:600
#2  0x00007f4437d92442 in __GI__IO_default_uflow (fp=0x20574f0) at genops.c:413
#3  0x00007f4437d840c2 in __GI__IO_getline_info (eof=0x0, extract_delim=<optimized out>, delim=10, n=199, buf=0x7ffefaaa51c0 "", 
    fp=0x20574f0, fp@entry=0x0) at iogetline.c:60
#4  __GI__IO_getline (fp=fp@entry=0x20574f0, buf=buf@entry=0x7ffefaaa51c0 "", n=n@entry=199, delim=delim@entry=10, 
    extract_delim=extract_delim@entry=1) at iogetline.c:34
#5  0x00007f4437d82f9d in _IO_fgets (buf=buf@entry=0x7ffefaaa51c0 "", n=n@entry=200, fp=fp@entry=0x20574f0) at iofgets.c:53
#6  0x000000000041a720 in fgets (__stream=0x20574f0, __n=200, __s=0x7ffefaaa51c0 "") at /usr/include/bits/stdio2.h:263
#7  SEC_GetPassword (input=input@entry=0x20574f0, output=output@entry=0x2057720, 
    prompt=prompt@entry=0x7ffefaaa5310 "Enter Password or Pin for \"softcard\":", ok=0x41a800 <SEC_BlindCheckPassword>) at secpwd.c:79
#8  0x00000000004132c2 in SECU_GetPasswordString (arg=<optimized out>, 
    prompt=0x7ffefaaa5310 "Enter Password or Pin for \"softcard\":") at secutil.c:103
#9  0x0000000000413626 in SECU_GetModulePassword (slot=0x2048a50, retry=0, arg=<optimized out>) at secutil.c:236
#10 0x00007f4438775c5f in pk11_GetPassword (wincx=0x0, retry=<optimized out>, slot=0x2048a50) at pk11auth.c:532
#11 PK11_DoPassword (slot=0x2048a50, session=2253, loadCerts=<optimized out>, wincx=0x0, alreadyLocked=0, contextSpecific=0)
    at pk11auth.c:602
#12 0x00007f44387768e0 in find_certs_from_nickname (nickname=0x20544b9 "ca_signing", nickname@entry=0x1fbedf0 "softcard:ca_signing", 
    wincx=wincx@entry=0x0) at pk11cert.c:783
#13 0x00007f443877780b in PK11_FindCertFromNickname (nickname=nickname@entry=0x1fbedf0 "softcard:ca_signing", wincx=wincx@entry=0x0)
    at pk11cert.c:853
#14 0x00007f44387abc16 in common_FindCertByNicknameOrEmailAddrForUsage (name=name@entry=0x1fbedf0 "softcard:ca_signing", 
    anyUsage=anyUsage@entry=1, lookingForUsage=lookingForUsage@entry=certUsageSSLClient, wincx=wincx@entry=0x0, handle=0x204aae0)
    at stanpcertdb.c:641
#15 0x00007f44387abde2 in CERT_FindCertByNicknameOrEmailAddrCX (handle=handle@entry=0x204aae0, 
    name=name@entry=0x1fbedf0 "softcard:ca_signing", wincx=wincx@entry=0x0) at stanpcertdb.c:687
#16 0x000000000041a070 in SECU_FindCertByNicknameOrFilename (handle=handle@entry=0x204aae0, 
    name=name@entry=0x1fbedf0 "softcard:ca_signing", ascii=0, pwarg=pwarg@entry=0x0) at secutil.c:3663
#17 0x000000000041069a in ValidateCert (pwdata=0x7ffefaaa56e0, ascii=<optimized out>, logit=0, checkSig=0, certUsage=<optimized out>, 
    date=0x0, name=<optimized out>, handle=0x204aae0) at certutil.c:712
#18 certutil_main (argc=<optimized out>, argv=<optimized out>, initialize=initialize@entry=1) at certutil.c:3240
#19 0x0000000000408d5b in main (argc=<optimized out>, argv=<optimized out>) at certutil.c:3680
Comment 10 Simo Sorce 2019-02-11 15:39:40 UTC 
This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.
Comment 11 Asha Akkiangady 2019-10-29 19:28:17 UTC 
Removing needinfo flag.
Note You need to log in before you can comment on or make changes to this bug.