Bob, do you know why NSS succeeds to import the certificate into the external token, but fails to set the trust on the internal token?

Would you be able to work on a patch to fix this issue?

FYI, the problem does not happen on another machine with FIPS disabled.

So apparently the issue is that the certificate is imported into the HSM and the trust is imported into the token. In non-fips mode, you can import trust without logging into the token, but in FIPS mode you do need log into the token to import trust.

You also need to log into the HSM to import trust. If you don't supply the -f password.txt, do you get prompted for both tokens?

If so, and you need to do this from scripts, you many need to import the cert into both the HSM and the internal token in 2 separate steps. Don't try to set the trust when importing into the HSM.

bob

Thanks Bob,

I tried importing the certificate as in step #5 without the password file, but I only got prompted for the HSM password and the command still failed with the same error message (i. not logged in).

However, I was able to import the certificate successfully using the two-steps workaround.

First (the order does matter), import the certificate into the HSM without the trust flags (the -t option is still required, but the HSM password is not):

 $ certutil -A -d nssdb -h hsm -n test -i test.crt -t ""

 $ certutil -L -d nssdb -h hsm
 
 Certificate Nickname                                         Trust Attributes
                                                              SSL,S/MIME,JAR/XPI
 
 Enter Password or Pin for "hsm":
 hsm:test                                                     ,,

Second, import the certificate into the internal token with the correct trust flags (the internal token password is required):

 $ certutil -A -d nssdb -n test -i test.crt -t "CT,C,C"
 Enter Password or Pin for "NSS FIPS 140-2 Certificate DB":

 $ certutil -L -d nssdb
 
 Certificate Nickname                                         Trust Attributes
                                                              SSL,S/MIME,JAR/XPI
 
 test                                                         CT,C,C

 $ certutil -L -d nssdb -h hsm
 
 Certificate Nickname                                         Trust Attributes
                                                              SSL,S/MIME,JAR/XPI
 
 Enter Password or Pin for "hsm":
 hsm:test                                                     CT,C,C

So I think the RHCS can be modified to use the two-step workaround, but do you think the certutil error in step #5 will eventually get fixed? I think there are several possibilities:

* The command in step #5 could generate a different error message explaining that the import needs to be done in two steps.
* Instead of generating an error, the command could just ignore the specified trust flags and simply return silently after importing the certificate into the HSM. The second step is still required.
* The command can take the internal token password and import the certificate into both HSM and internal token in a single step. As shown above, the HSM password is not required for import. But this option could be confusing since the -h and the -f options will refer to different tokens.

In the first step of the workaround, apparently if the certificate key is stored in the HSM the HSM password is required (and the command still fails even without the trust flags). If the certificate key is not stored in the HSM the HSM password is not required (and the command will complete successfully without the trust flags).

The workaround for RHCS was implemented in bug #1395817.

Re-opening for tracking. Potential solution created upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1782980

certutil can support multiple passwords but it won't try to authenticate to the internal token when setting trust, even if it has the softokn password.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

reopenning and setting the stale date to the new NSS rebase.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.