Wan-Teh Chang wrote: > Nelson Bolyard wrote: >> I tried the above command when the module was not in FIPS mode, and the >> above command also failed. >> ERROR: Token "NSS FIPS 140-2 Certificate DB" not found. > > Try the token name "NSS Certificate DB" in non-FIPS mode.
I am trying to reproduce the behavior David reported, using the command that he reportedly used. We should be able to reproduce what he experienced. He reported that the command > modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir . succeeded, even though he entered "password" as the new password. I was testing the hypothesis that perhaps the softoken module was not actually in FIPS mode, but the command succeeded anyway, despite having the FIPS mode token name string in it, rather than the non-FIPS token name. My test concluded that if his module was in non-FIPS mode, the above command would fail due to the slot name mismatch. I considered the possibility that the modutil command failed silently, appearing to have succeeded. But in that case, the new password should not have "taken", and should not have worked thereafter, and David reports that it DID work thereafter. So, I conclude that the command must have succeeded. I considered that there are somehow two sets of DBs involved (at least two secmod.db's) and that the secmod.db on which modutil was working is not the secmod.db being used by his other application. I thought perhaps modutil runs the softoken module in FIPS mode, and his application is running the module in non-FIPS mode, with the same cert/key DB pair. Or something like that. But that doesn't help explain how modutil could change the password to "password" while it has loaded the module in FIPS mode. So, at this point, the only remaining untested hypothesis I have is that this is a difference between 3.11.2 and 3.11.3. -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
