Hide Forgot
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): nss-tools-3.21.0-17.el7 How reproducible: always 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>>' 6. * certutil -d sql:/etc/pki/nssdb/ -h '$label' -f pin -D -n 'Example CA:tmpname' or * 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.
#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
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.
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?
Isn't this related to bz1395301 btw?
(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.
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(). bob
I've submitted a suggested fix upstream, as it's little work, and as it might help for bug 1088366.
I've attached an additional patch for the delete scenario to https://bugzilla.mozilla.org/show_bug.cgi?id=1424282
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. https://access.redhat.com/errata/RHEA-2018:0679