Description of problem:
When attempting to initialize JSS after another component of the application uses another security provider which is also backed by NSS (such as the JDK's newer PK11 security provider), JSS will will inherit the properties and configuration of the first provider to initialize the underlying NSS, such as read-only tokens/slots when JSS is attempted to be initialized in read-write mode.


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


How reproducible: 100%


Steps to Reproduce:
1. Use a security provider which is backed by NSS other than JSS
2. Initialize JSS with a configuration that differs from the first security provider (read-only vs read-write is a very obvious config to use and examine)
3. Fetch a CryptoToken instance from the JSS CryptoManager and examine its properties. In the case of its writability, it will have the mode set by the first security provider rather than that set during JSS initialization.

Actual results:
JSS's CryptoToken inherits the configuration of the first security provider's NSS initialization

Expected results:
JSS's CryptoToken is configured as expected from the configuration provided during JSS initialization

Additional info:
This scenario may be common for Java-based web applications, where the servlet engine (Tomcat) may do its own crypto operations using non-JSS security providers.