Bug 1375540 - certutil asks for PIN even though "-f ..." is specified for trust modification (-M) operations
Summary: certutil asks for PIN even though "-f ..." is specified for trust modificatio...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact: Stanislav Zidek
Depends On:
Blocks: 1524672
TreeView+ depends on / blocked
Reported: 2016-09-13 10:58 UTC by Stanislav Zidek
Modified: 2018-04-10 09:25 UTC (History)
6 users (show)

Fixed In Version: nss-3.34.0-0.1.beta1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1524672 (view as bug list)
Last Closed: 2018-04-10 09:23:57 UTC
Target Upstream Version:

Attachments (Terms of Use)
idea v1 (1.06 KB, patch)
2017-03-08 22:07 UTC, Kai Engert (:kaie) (inactive account)
no flags Details | Diff

System ID Priority Status Summary Last Updated
Mozilla Foundation 1395897 -- RESOLVED certutil shouldn't prompt for password if -f is given 2020-07-21 10:55:48 UTC
Red Hat Bugzilla 1088366 None CLOSED Upstream test suite fails in FIPS mode 2019-06-11 12:22:33 UTC
Red Hat Product Errata RHEA-2018:0679 None None None 2018-04-10 09:25:17 UTC

Internal Links: 1088366

Description Stanislav Zidek 2016-09-13 10:58:59 UTC
Description of problem:
When trying to modify or delete a certificate in softhsm module, certutil -M and -D explicitly asks for pin, even though it's specified in the file and -f ... is used.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. export PIN=1234
2. echo $PIN >pin
3. softhsm2-util --init-token --free --label softhsm --pin $PIN --so-pin $PIN
4. modutil -dbdir sql:/etc/pki/nssdb/ -add softhsm -libfile /usr/lib64/pkcs11/libsofthsm2.so
5. p11tool --so-login --batch --label 'Example CA' --mark-trusted --mark-ca --load-certificate <<CA cert>> --write '<<TOKEN>>'
  * certutil -d sql:/etc/pki/nssdb/ -h '$label' -f pin -D -n 'Example CA:tmpname'
  * certutil -d sql:/etc/pki/nssdb/ -h '$label' -f pin -M -n 'Example CA:tmpname' -t 'C,,'

Actual results:
Enter Password or Pin for "softhsm":

Expected results:
file 'pin' is used and pin read from it

Additional info:
Surprisingly, some operations work well (-A), i.e. read pin from file if specified and ask otherwise.

Comment 6 Kai Engert (:kaie) (inactive account) 2017-03-08 21:45:01 UTC
#8  0x0000000000413122 in SECU_GetPasswordString (arg=<optimized out>, prompt=0x7fffffffde30 "Enter Password or Pin for \"softhsm\":") at secutil.c:99
#9  0x000000000041351c in SECU_GetModulePassword (slot=0x68b630, retry=0, arg=<optimized out>) at secutil.c:232
#10 0x00007ffff766fc9d in pk11_GetPassword (wincx=0x0, retry=0, slot=0x68b630) at pk11auth.c:545
#11 PK11_DoPassword (slot=0x68b630, session=1, loadCerts=<optimized out>, wincx=0x0, alreadyLocked=0, contextSpecific=0) at pk11auth.c:615
#12 0x00007ffff7670fba in PK11_FindCertFromNickname (nickname=0x695f78 "Example CA", nickname@entry=0x62d6c0 "softhsm:Example CA", wincx=wincx@entry=0x0) at pk11cert.c:555
#13 0x00007ffff76a4891 in common_FindCertByNicknameOrEmailAddrForUsage (name=name@entry=0x62d6c0 "softhsm:Example CA", anyUsage=anyUsage@entry=1, lookingForUsage=lookingForUsage@entry=certUsageSSLClient, handle=0x68d4a0) at stanpcertdb.c:622
#14 0x00007ffff76a48ef in CERT_FindCertByNicknameOrEmailAddr (handle=handle@entry=0x68d4a0, name=name@entry=0x62d6c0 "softhsm:Example CA") at stanpcertdb.c:661
#15 0x0000000000410776 in ChangeTrustAttributes (pwdata=0x7fffffffe1d0, trusts=0x7fffffffe6c9 "C,,", name=0x62d6c0 "softhsm:Example CA", slot=0x68b630, handle=0x68d4a0) at certutil.c:368
#16 certutil_main (argc=<optimized out>, argv=<optimized out>, initialize=initialize@entry=1) at certutil.c:3229
#17 0x000000000040932b in main (argc=<optimized out>, argv=<optimized out>) at certutil.c:3703

Comment 7 Kai Engert (:kaie) (inactive account) 2017-03-08 22:06:11 UTC
We have too many scenarios where the password information isn't passed down to functions, because APIs don't support it.

In this case, our code calls CERT_FindCertByNicknameOrEmailAddr, which doesn't support passing along password information, but that token is "unfriendly" (requires authentication to list certificates), and so we're stuck.

Comment 8 Kai Engert (:kaie) (inactive account) 2017-03-08 22:07:47 UTC
Created attachment 1261391 [details]
idea v1

Bob, do you think this could work realiably?

If not, should we introduce another variation of API CERT_FindCertByNicknameOrEmailAddr which takes wincx as an additional parameter?

Comment 9 Stanislav Zidek 2017-03-10 14:07:34 UTC
Isn't this related to bz1395301 btw?

Comment 10 Kai Engert (:kaie) (inactive account) 2017-03-15 16:46:51 UTC
(In reply to Stanislav Zidek from comment #9)
> Isn't this related to bz1395301 btw?

Similar symptom, but completely different code path, and a different fix required.

Comment 11 Bob Relyea 2017-03-23 17:46:42 UTC
Yes, I think that's a reasonable work around. Long term we should create a version that takes a cx.

NOTE: as coded, there is a potential reference leak. You'll need to free any cert returned from CERT_FindCertByNickname().


Comment 14 Kai Engert (:kaie) (inactive account) 2017-09-01 11:00:23 UTC
I've submitted a suggested fix upstream, as it's little work, and as it might help for bug 1088366.

Comment 23 Kai Engert (:kaie) (inactive account) 2017-12-08 16:02:06 UTC
I've attached an additional patch for the delete scenario to

Comment 33 errata-xmlrpc 2018-04-10 09:23:57 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.


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