BC-FIPS and CACERTS

[longshot]

I 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.

[mchoma]

Something is calling SSLContext.getInstance("Default") internally, could you void that and use e.g. SSLContext.getInstance("TLS") ?

I think in past you had different problem - you weren't trusting server. It can occur once you get over current problem.

But now you are not so far.

[longshot]

If you look at the stack trace this is happening when the URL tries to open a connection to the XML file to stream.  I'm not explicitly calling this.

Is there anyway to set the configure "Default" to something else?

[jewellgm]

You can try to set the following system property when launching Wildfly:

https.protocols=TLSv1.2

I don't know whether Wildfly overrides that anywhere.

[longshot]

So here is what I have done to get things to work.

I have not done exhaustive testing. 

But. my problem has gone away.

in java.security

I changed the keystore.type to be:

keystore.type=BCFKS

Then using the keytool and the bc-fips-1.0.0.jar  I created a new cacerts that is of type BCFKS.  I actually exported everything that was in the original cacerts from java, imported those plus my root cert which is what we needed in the first place. 

Since this is the BC FIPS provider, I also had to set the java option -Djavax.net.ssl.trustStorePassword=changeit

The last I don't really care for,. but based on the source, it looks like I either set the password with this property or I don't have a password on the truststore and you can't create a truststore with keytool without a password.

The last thing I don't know about, or I should say I'm very unclear about is that I have a truststore configured in wildfly that doesn't appear to be being used.  I'm not sure if it's just that I did it wrong?  Or what.  Is there some way I can figure out if anything uses it? 

[jaikiran]

The last thing I don't know about, or I should say I'm very unclear about is that I have a truststore configured in wildfly that doesn't appear to be being used.  I'm not sure if it's just that I did it wrong?  Or what.  Is there some way I can figure out if anything uses it?

Where and how is it configured?