-
Bug
-
Resolution: Done
-
Major
-
7.1.0.DR8
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:
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
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.
- is cloned by
-
-
- Resolved
-