]
Stuart Douglas resolved WFCORE-2056.
------------------------------------
Fix Version/s: 3.0.0.Alpha15
Resolution: Done
wildfly-openssl - wfssl.dll is not automatically loaded on Windows
------------------------------------------------------------------
Key: WFCORE-2056
URL:
https://issues.jboss.org/browse/WFCORE-2056
Project: WildFly Core
Issue Type: Bug
Components: Security, Server
Environment: Windows 8.1 Pro, 64b
OpenSSL taken from JBCS 2.4.6 (OpenSSL 1.0.1e)
Reporter: Stuart Douglas
Assignee: Stuart Douglas
Labels: wilfly-openssl
Fix For: 3.0.0.Alpha15
It seems that libraries to support OpenSSL via {{wildfly-openssl}} does not bind
automatically under the Windows right now.
When I am on Linux, to setup OpenSSL, all I need to do is to have installed OpenSSL on my
machine or provide path to my custom OpenSSL libs via "org.wildfly.openssl.path"
property. Then I start EAP, set up "openssl.TLS" provider and I am ready to go.
On windows although this seems to be a little bit complicated. When I start EAP with path
to my OpenSSL libraries (JBCS OpenSSL) and set up "openssl.TLS" provider, after
reload operation I get following error message:
{code}
2016-11-28 12:27:44,512 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
MSC000001: Failed to start service
jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context:
org.jboss.msc.service.StartException in service
jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context:
WFLYDM0018: Unable to start service
at
org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:108)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation
(algorithm: openssl.TLS, provider: openssl, class:
org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
at java.security.Provider$Service.newInstance(Unknown Source)
at sun.security.jca.GetInstance.getInstance(Unknown Source)
at sun.security.jca.GetInstance.getInstance(Unknown Source)
at javax.net.ssl.SSLContext.getInstance(Unknown Source)
at
org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:97)
... 5 more
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at org.wildfly.openssl.SSL.init(SSL.java:81)
at
org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:119)
at
org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:427)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
... 10 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.wildfly.openssl.SSL.init(SSL.java:76)
... 16 more
Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:188)
... 21 more
{code}
It seems that "wfssl" library that serves to search and bind OpenSSL libs does
not load automatically although it is already present as a module in EAP. When I specify
also {{org.wildfly.openssl.libwfssl.path}} property with path to the {{wfssl.dll}} file in
the EAP modules, then OpenSSL is successfully initialized during the EAP startup and https
requests from clients seems to be working too.
My expectation here is that when "wfssl.dll" library is present as a module in
EAP on Windows, it is loaded automatically and user does not have to specify its location.