Currently if CryptoManager.initialize() fails it will throw a generic exception: java.lang.SecurityException: Unable to initialize security library Troubleshooting such problem is difficult because there are many possibilities that will generate the same error message. Per discussion with jmagne, JSS should be able to get a more specific error code from NSS using PORT_GetError. The error code can then be stored as an attribute in the exception object so the caller can inspect the error code and handle it properly, or simply display the error code so user can investigate the problem. Alternatively, JSS can also throw a more specific subclass of SecurityException that corresponds to each error code. The problem may not be limited to CryptoManager.initialize(). Other JSS methods should be reviewed to make sure it passes the error code from NSS to the caller.
I agree the NSS error code should be available, as well as the NSS error description that matches the error code. For better or worse NSS does not provide an entry point to get the error message, you have to code this yourself and it requires access to 3 different error header files (NSPRerrs.h, SECerrs.h, SLerrs.h) which contain the message strings. python-nss implements this in py_nspr_error.c, I know other applications have done similar things, if you search for use of those header files you'll probably find it. You may also want to look at NSS utility code (which is not exported as a library). Look in cmd/lib/basicutil.c But ... don't think just because you've got an NSS error code and/or message that's it's going to help you :-( NSS is notorious for returning bogus unhelpful errors which are often unrelated to the actual problem. Based on lots of experience I've learned if you actually need to understand what went wrong you're going to have to run the code under the debugger and trace through it I'm sorry to say. :-( It would have been a way better design if NSS internally used more than just an error code, but instead also formatted a dynamic error string with the specific problem. As it stands now you'll get an error code something like INVALID_KEY but you'll have no idea why that key was invalid which could be any of a dozen reasons. Argh!!!
Although NSS may not provide specific enough error code, JSS should still return the NSS error code so failures can be investigated without requiring a custom build to provide some additional debugging information. Once this is implemented, NSS-related issues can be investigated more quickly.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.