Re: [wildfly-dev] Supporting FIPS in domain mode

The problem with this issue is that it is going to be quite complex to solve, especially once we start to expand on all the scenarios we need to support. Add to that it becomes even more complex once we need to consider backwards compatibility. Generally the scenarios we need are: - - Using a FIPS configured JVM - Using a non-FIPS configured JVM Combined with: - - TLS enabled for the host controller connection. - TLS not enabled. Although the issue raised only talks about an error message for one we need to ensure we cover them all. Firstly the connection that is being talked about here is the connection from the individual application server process back to it's host controller all running on the same machine. The reason for the simple trusting solution is because although a connection is used it is always local - the reason we need to be able to support TLS for this connection is because we connect to the same Remoting connector as remote clients also used so once TLS is enabled it is enabled for all. Firstly I think it is worth exploring if there is anything else we can do to automatically configure the client side of this connection without requiring any additional configuration from the administrator. If we can identify the certificate the server will be using for the connection there may be something we can do to send this to the application server process so that it can instantiate a SunJSSE compatible KeyStore and subsequently a SunJSSE TrustManager that will be accepted into the SSLContext. When it comes to host controller and application server initialisation those two processes are always guaranteed to be the same version so this gives us some leeway on how the application server process is initially configured. If that is not possible then an alternative is that to achieve a FIPS mode compliant connection from the application server to the host controller is going to require a custom configuration. The problem is we do not have the management model available on the application server at this time so we would probably still need a way to define it within the host controller and convert it to a format that can be used on the application server. In this case I don't think using the standard system properties would be a good idea as existing installations could already be relying on these elsewhere. If we needed to go down the custom configuration route then I would suggest lack of configuration means stick with the current behaviour so existing installations are unaffected leaving the configuration to be set by those that do require it. If automatically obtaining the certificate is viable then that could be used for all cases without breaking compatibility but additional verification is probably needed there. Regards, Darran Lofthouse. On 19/11/15 10:25, Ryan Emerson wrote: