BC-FIPS and CACERTS
longshot Nov 17, 2017 4:19 PMI have configured a wildfly to use BC-FIPS as the security provider and I have configured a keystore of type BCFKS to work with it. I added the provider to java.security as the first provider and added BCFIPS to the internal SSL provider.
I added by BCFKS keystore to the application as a keystore and truststore.
Part of my application code, on the server is opening a stream on a URL using https (basically client calls to server to get a page, the page is actually constructed from applying XSL to an XML file and sending the html back. When we are trying to parse the XML, by opening a stream on the URL that we get the following error:
Failed to transform https://localhost:8443/Applic/Support/formdata_menus.xml using https://localhost:8443/Applic/Support/menuToJS.xsl: java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)
at javax.net.ssl.DefaultSSLSocketFactory.throwException(SSLSocketFactory.java:248)
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:255)
lots of other error lines,
at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)
at java.security.Provider$Service.newInstance(Provider.java:1617)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96)
at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:122)
at javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:332)
at javax.net.ssl.HttpsURLConnection.<init>(HttpsURLConnection.java:289)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.<init>(HttpsURLConnectionImpl.java:85)
at sun.net.www.protocol.https.Handler.openConnection(Handler.java:62)
at sun.net.www.protocol.https.Handler.openConnection(Handler.java:57)
at java.net.URL.openConnection(URL.java:979)
... 116 more
Caused by: java.security.KeyStoreException: FIPS mode: KeyStore must be from provider BCFIPS
at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:67)
at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
at sun.security.ssl.SSLContextImpl$DefaultSSLContext.getDefaultKeyManager(SSLContextImpl.java:874)
at sun.security.ssl.SSLContextImpl$DefaultSSLContext.<init>(SSLContextImpl.java:732)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at java.security.Provider$Service.newInstance(Provider.java:1595)
Now, in the past we've had issues with this code when we turned on standard SSL. I was not involved so I can't say if this is the EXACT same issue. But it was solved by adding the root cert to java's cacert in java.security. That's not really going to work as this is a jks keystore and we can only read BCFKS. And this is mentioning Keystore instead of the truststore I'm wondering should I be trying to configure the java that runs this application to point to my bcfks keystore as a truststore? And would I be doing that by setting system properties for javax.net.ssl.trustStore, javax.net.ssl.trustStoreType, and javax.net.ssl.trustStorePassword? Or should I create a separate bcfks truststore with just the root cert ?
I should mention that I don't know that my truststore configuration is correct in my standalone.xml. But given the fact that we had a similar issue with these forms when we first turned on SSL and it was solved by adding the root cert to the java running wildfly's cacerts, I don't know that the truststore we set up in wildfly is or ever has be set correctly. Or it just could be that given the weird way we are generating the html for these screens on the back end is why we needed to use cacerts. I've tried two different configurations for my truststore
This was my original configuration:
<truststore relative-to="jboss.server.config.dir" path="localhost.truststore" keystore-password="PASSWORD" provider="BCFKS"/>
Then I thought, maybe it shouldn't be .truststore, so changed it to the actual name:
<truststore relative-to="jboss.server.config.dir" path="localhost.bcfks" keystore-password="PASSWORD" provider="BCFKS"/>
Thoughts? Any help would be appreciated.