[JBoss JIRA] (WFCORE-2908) Per application Expressions driven by the management model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2908?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2908:
------------------------------------------
Anyone interested in working on this *must* talk to [~jmesnil] first, to ensure that proper consideration of any intersection with the Microprofile Config API work at https://github.com/wildfly-extras/wildfly-microprofile-config is done.
> Per application Expressions driven by the management model
> ----------------------------------------------------------
>
> Key: WFCORE-2908
> URL: https://issues.jboss.org/browse/WFCORE-2908
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Juergen Weber
>
> This is the core side part of WFLY-8868. The overall request involves being able to include a properties attribute as part of a management model deployment resource, with those properties then being available to expression resolution, the same way env vars, system props, vault values and META-INF/jboss-properties values are. The core side aspect of this is to maintain the props in the model and make those values available to the DeploymentUnitProcessors. The WildFly full side part is to enhance the existing ee subsystem DUPs that deal with expression resolution to have them take advantage of this new source of resolution data.
> This basically is an improvement on the existing META-INF/jboss-properties facility by allowing the admin to control the resolution without having to mess with the deployment content.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (REMJMX-144) Elytron, JMX client fails to work when the JVM is running in FIPS mode
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-144?page=com.atlassian.jira.plugin... ]
Darran Lofthouse resolved REMJMX-144.
-------------------------------------
Resolution: Done
> Elytron, JMX client fails to work when the JVM is running in FIPS mode
> ----------------------------------------------------------------------
>
> Key: REMJMX-144
> URL: https://issues.jboss.org/browse/REMJMX-144
> Project: Remoting JMX
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta6
>
>
> The JMX client fails to work when the JVM is running in FIPS mode.
> There should be possible to configure client ssl context with Elytron. However doing so, still javax.net.ssl.SSLContext.getDefault() is called which fails with the following stacktrace:
> {code:title=server.log}
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Completed open of endpoint "endpoint" <67ce59be>
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 1 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote)
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote': Remoting remote connection provider 42a0d0b7 for endpoint "endpoint" <67ce59be>
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 2 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+tls)
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+tls': Remoting remote connection provider 7dc22d9b for endpoint "endpoint" <67ce59be>
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 3 of endpoint "endpoint" <67ce59be> (opened Connection provider for remoting)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remoting': Remoting remote connection provider 194d9579 for endpoint "endpoint" <67ce59be>
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 4 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+http)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+http': Remoting remote connection provider 21f0cb0a for endpoint "endpoint" <67ce59be>
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 5 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+https)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+https': Remoting remote connection provider 27b862 for endpoint "endpoint" <67ce59be>
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 6 of endpoint "endpoint" <67ce59be> (opened Connection provider for http-remoting)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'http-remoting': Remoting remote connection provider 422cda30 for endpoint "endpoint" <67ce59be>
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 7 of endpoint "endpoint" <67ce59be> (opened Connection provider for https-remoting)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'https-remoting': Remoting remote connection provider 55cb3d77 for endpoint "endpoint" <67ce59be>
> 10:55:00,764 WARN [org.jboss.remotingjmx.Util] (default task-1) The protocol 'remoting-jmx' is deprecated, instead you should use 'remote'.
> 10:55:00,764 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://localhost:9999, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[null], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-port=9999]
> 10:55:00,764 WARN [org.jboss.remotingjmx.Util] (default task-1) The protocol 'remoting-jmx' is deprecated, instead you should use 'remote'.
> 10:55:00,765 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://localhost:9999, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-port=9999]
> 10:55:00,772 INFO [stdout] (default task-1) *** Error:JBREM000212: Failed to configure SSL context
> 10:55:00,773 ERROR [stderr] (default task-1) java.io.IOException: JBREM000212: Failed to configure SSL context
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497)
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:487)
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:241)
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:158)
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:105)
> 10:55:00,773 ERROR [stderr] (default task-1) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> 10:55:00,773 ERROR [stderr] (default task-1) at com.redhat.eap.qe.fips.standalone.elytron.client.jmx.JmxClientServlet.doGet(JmxClientServlet.java:33)
> 10:55:00,773 ERROR [stderr] (default task-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 10:55:00,773 ERROR [stderr] (default task-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 10:55:00,773 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 10:55:00,774 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,774 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
> 10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 10:55:00,776 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 10:55:00,776 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 10:55:00,776 ERROR [stderr] (default task-1) at java.lang.Thread.run(Thread.java:745)
> 10:55:00,776 ERROR [stderr] (default task-1) Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)
> 10:55:00,776 ERROR [stderr] (default task-1) at java.security.Provider$Service.newInstance(Provider.java:1617)
> 10:55:00,776 ERROR [stderr] (default task-1) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> 10:55:00,776 ERROR [stderr] (default task-1) at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> 10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> 10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96)
> 10:55:00,777 ERROR [stderr] (default task-1) at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:183)
> 10:55:00,777 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:495)
> 10:55:00,777 ERROR [stderr] (default task-1) ... 46 more
> 10:55:00,777 ERROR [stderr] (default task-1) Caused by: java.security.KeyStoreException: FIPS mode: KeyStore must be from provider SunPKCS11-testPkcs
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:67)
> 10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.SSLContextImpl$DefaultSSLContext.getDefaultKeyManager(SSLContextImpl.java:874)
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.SSLContextImpl$DefaultSSLContext.<init>(SSLContextImpl.java:732)
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 10:55:00,778 ERROR [stderr] (default task-1) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 10:55:00,778 ERROR [stderr] (default task-1) at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> 10:55:00,778 ERROR [stderr] (default task-1) at java.security.Provider$Service.newInstance(Provider.java:1595)
> 10:55:00,778 ERROR [stderr] (default task-1) ... 52 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (REMJMX-144) Elytron, JMX client fails to work when the JVM is running in FIPS mode
by Darran Lofthouse (JIRA)
Darran Lofthouse created REMJMX-144:
---------------------------------------
Summary: Elytron, JMX client fails to work when the JVM is running in FIPS mode
Key: REMJMX-144
URL: https://issues.jboss.org/browse/REMJMX-144
Project: Remoting JMX
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
Fix For: 3.0.0.Beta5
The JMX client fails to work when the JVM is running in FIPS mode.
There should be possible to configure client ssl context with Elytron. However doing so, still javax.net.ssl.SSLContext.getDefault() is called which fails with the following stacktrace:
{code:title=server.log}
10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Completed open of endpoint "endpoint" <67ce59be>
10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 1 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote)
10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote': Remoting remote connection provider 42a0d0b7 for endpoint "endpoint" <67ce59be>
10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 2 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+tls)
10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+tls': Remoting remote connection provider 7dc22d9b for endpoint "endpoint" <67ce59be>
10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 3 of endpoint "endpoint" <67ce59be> (opened Connection provider for remoting)
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remoting': Remoting remote connection provider 194d9579 for endpoint "endpoint" <67ce59be>
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 4 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+http)
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+http': Remoting remote connection provider 21f0cb0a for endpoint "endpoint" <67ce59be>
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 5 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+https)
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+https': Remoting remote connection provider 27b862 for endpoint "endpoint" <67ce59be>
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 6 of endpoint "endpoint" <67ce59be> (opened Connection provider for http-remoting)
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'http-remoting': Remoting remote connection provider 422cda30 for endpoint "endpoint" <67ce59be>
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 7 of endpoint "endpoint" <67ce59be> (opened Connection provider for https-remoting)
10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'https-remoting': Remoting remote connection provider 55cb3d77 for endpoint "endpoint" <67ce59be>
10:55:00,764 WARN [org.jboss.remotingjmx.Util] (default task-1) The protocol 'remoting-jmx' is deprecated, instead you should use 'remote'.
10:55:00,764 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://localhost:9999, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[null], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-port=9999]
10:55:00,764 WARN [org.jboss.remotingjmx.Util] (default task-1) The protocol 'remoting-jmx' is deprecated, instead you should use 'remote'.
10:55:00,765 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://localhost:9999, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-port=9999]
10:55:00,772 INFO [stdout] (default task-1) *** Error:JBREM000212: Failed to configure SSL context
10:55:00,773 ERROR [stderr] (default task-1) java.io.IOException: JBREM000212: Failed to configure SSL context
10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497)
10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:487)
10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:241)
10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:158)
10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:105)
10:55:00,773 ERROR [stderr] (default task-1) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
10:55:00,773 ERROR [stderr] (default task-1) at com.redhat.eap.qe.fips.standalone.elytron.client.jmx.JmxClientServlet.doGet(JmxClientServlet.java:33)
10:55:00,773 ERROR [stderr] (default task-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
10:55:00,773 ERROR [stderr] (default task-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
10:55:00,773 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
10:55:00,774 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
10:55:00,774 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
10:55:00,776 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
10:55:00,776 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
10:55:00,776 ERROR [stderr] (default task-1) at java.lang.Thread.run(Thread.java:745)
10:55:00,776 ERROR [stderr] (default task-1) Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)
10:55:00,776 ERROR [stderr] (default task-1) at java.security.Provider$Service.newInstance(Provider.java:1617)
10:55:00,776 ERROR [stderr] (default task-1) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
10:55:00,776 ERROR [stderr] (default task-1) at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96)
10:55:00,777 ERROR [stderr] (default task-1) at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:183)
10:55:00,777 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:495)
10:55:00,777 ERROR [stderr] (default task-1) ... 46 more
10:55:00,777 ERROR [stderr] (default task-1) Caused by: java.security.KeyStoreException: FIPS mode: KeyStore must be from provider SunPKCS11-testPkcs
10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:67)
10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.SSLContextImpl$DefaultSSLContext.getDefaultKeyManager(SSLContextImpl.java:874)
10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.SSLContextImpl$DefaultSSLContext.<init>(SSLContextImpl.java:732)
10:55:00,777 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
10:55:00,777 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
10:55:00,778 ERROR [stderr] (default task-1) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
10:55:00,778 ERROR [stderr] (default task-1) at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
10:55:00,778 ERROR [stderr] (default task-1) at java.security.Provider$Service.newInstance(Provider.java:1595)
10:55:00,778 ERROR [stderr] (default task-1) ... 52 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (REMJMX-144) Elytron, JMX client fails to work when the JVM is running in FIPS mode
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-144?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated REMJMX-144:
------------------------------------
Fix Version/s: 3.0.0.Beta6
(was: 3.0.0.Beta5)
> Elytron, JMX client fails to work when the JVM is running in FIPS mode
> ----------------------------------------------------------------------
>
> Key: REMJMX-144
> URL: https://issues.jboss.org/browse/REMJMX-144
> Project: Remoting JMX
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta6
>
>
> The JMX client fails to work when the JVM is running in FIPS mode.
> There should be possible to configure client ssl context with Elytron. However doing so, still javax.net.ssl.SSLContext.getDefault() is called which fails with the following stacktrace:
> {code:title=server.log}
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Completed open of endpoint "endpoint" <67ce59be>
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 1 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote)
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote': Remoting remote connection provider 42a0d0b7 for endpoint "endpoint" <67ce59be>
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 2 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+tls)
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+tls': Remoting remote connection provider 7dc22d9b for endpoint "endpoint" <67ce59be>
> 10:55:00,762 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 3 of endpoint "endpoint" <67ce59be> (opened Connection provider for remoting)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remoting': Remoting remote connection provider 194d9579 for endpoint "endpoint" <67ce59be>
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 4 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+http)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+http': Remoting remote connection provider 21f0cb0a for endpoint "endpoint" <67ce59be>
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 5 of endpoint "endpoint" <67ce59be> (opened Connection provider for remote+https)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'remote+https': Remoting remote connection provider 27b862 for endpoint "endpoint" <67ce59be>
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 6 of endpoint "endpoint" <67ce59be> (opened Connection provider for http-remoting)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'http-remoting': Remoting remote connection provider 422cda30 for endpoint "endpoint" <67ce59be>
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Allocated tick to 7 of endpoint "endpoint" <67ce59be> (opened Connection provider for https-remoting)
> 10:55:00,763 TRACE [org.jboss.remoting.endpoint] (default task-1) Adding connection provider registration named 'https-remoting': Remoting remote connection provider 55cb3d77 for endpoint "endpoint" <67ce59be>
> 10:55:00,764 WARN [org.jboss.remotingjmx.Util] (default task-1) The protocol 'remoting-jmx' is deprecated, instead you should use 'remote'.
> 10:55:00,764 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://localhost:9999, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[null], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-port=9999]
> 10:55:00,764 WARN [org.jboss.remotingjmx.Util] (default task-1) The protocol 'remoting-jmx' is deprecated, instead you should use 'remote'.
> 10:55:00,765 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://localhost:9999, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-port=9999]
> 10:55:00,772 INFO [stdout] (default task-1) *** Error:JBREM000212: Failed to configure SSL context
> 10:55:00,773 ERROR [stderr] (default task-1) java.io.IOException: JBREM000212: Failed to configure SSL context
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497)
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:487)
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:241)
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:158)
> 10:55:00,773 ERROR [stderr] (default task-1) at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:105)
> 10:55:00,773 ERROR [stderr] (default task-1) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> 10:55:00,773 ERROR [stderr] (default task-1) at com.redhat.eap.qe.fips.standalone.elytron.client.jmx.JmxClientServlet.doGet(JmxClientServlet.java:33)
> 10:55:00,773 ERROR [stderr] (default task-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 10:55:00,773 ERROR [stderr] (default task-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 10:55:00,773 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 10:55:00,774 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 10:55:00,774 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,774 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 10:55:00,775 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 10:55:00,775 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
> 10:55:00,776 ERROR [stderr] (default task-1) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 10:55:00,776 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 10:55:00,776 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 10:55:00,776 ERROR [stderr] (default task-1) at java.lang.Thread.run(Thread.java:745)
> 10:55:00,776 ERROR [stderr] (default task-1) Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)
> 10:55:00,776 ERROR [stderr] (default task-1) at java.security.Provider$Service.newInstance(Provider.java:1617)
> 10:55:00,776 ERROR [stderr] (default task-1) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> 10:55:00,776 ERROR [stderr] (default task-1) at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> 10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> 10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96)
> 10:55:00,777 ERROR [stderr] (default task-1) at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:183)
> 10:55:00,777 ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:495)
> 10:55:00,777 ERROR [stderr] (default task-1) ... 46 more
> 10:55:00,777 ERROR [stderr] (default task-1) Caused by: java.security.KeyStoreException: FIPS mode: KeyStore must be from provider SunPKCS11-testPkcs
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:67)
> 10:55:00,777 ERROR [stderr] (default task-1) at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.SSLContextImpl$DefaultSSLContext.getDefaultKeyManager(SSLContextImpl.java:874)
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.security.ssl.SSLContextImpl$DefaultSSLContext.<init>(SSLContextImpl.java:732)
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 10:55:00,777 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 10:55:00,778 ERROR [stderr] (default task-1) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 10:55:00,778 ERROR [stderr] (default task-1) at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> 10:55:00,778 ERROR [stderr] (default task-1) at java.security.Provider$Service.newInstance(Provider.java:1595)
> 10:55:00,778 ERROR [stderr] (default task-1) ... 52 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8884) Cipher token can't retrieve key store reference - IllegalStateException
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8884?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-11333 to WFLY-8884:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8884 (was: JBEAP-11333)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: No Release
(was: 7.1.0.DR19)
> Cipher token can't retrieve key store reference - IllegalStateException
> -----------------------------------------------------------------------
>
> Key: WFLY-8884
> URL: https://issues.jboss.org/browse/WFLY-8884
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: No Release
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Configuring the new cipher token with the above commands results in:
> {noformat}
> 07:42:38,759 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.clustering.jgroups.channel-factory.udp.AUTH: org.jboss.msc.service.StartException in service org.wildfly.clustering.jgroups.channel-factory.udp.AUTH: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.wildfly.clustering.service.InjectedValueDependency.getValue(InjectedValueDependency.java:51)
> at org.jboss.as.clustering.jgroups.subsystem.CipherAuthTokenBuilder.apply(CipherAuthTokenBuilder.java:75)
> at org.jboss.as.clustering.jgroups.subsystem.CipherAuthTokenBuilder.apply(CipherAuthTokenBuilder.java:52)
> at java.util.function.Function.lambda$andThen$1(Function.java:88)
> at org.wildfly.clustering.service.FunctionalValueService.getValue(FunctionalValueService.java:62)
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> at org.jboss.msc.service.ServiceRegistrationImpl.getValue(ServiceRegistrationImpl.java:199)
> at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672)
> at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:2001)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1950)
> ... 3 more
> {noformat}
> Which looks like bad timing when attempting to retrieve the key store reference, according to {{Value<T>#getValue()}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8868) per application Expressions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8868?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-8868:
----------------------------------------
Another thing to be aware of is the Microprofile Config API and an impl of that that [~jmesnil] developed for use in WildFly-based servers (particularly WildFly Swarm):
https://github.com/wildfly-extras/wildfly-microprofile-config
That proposed standard is about another way of making configuration variables available to applications. I'm not sure how what's been done there would intersect with this.
> per application Expressions
> ---------------------------
>
> Key: WFLY-8868
> URL: https://issues.jboss.org/browse/WFLY-8868
> Project: WildFly
> Issue Type: Feature Request
> Components: EE
> Reporter: Juergen Weber
>
> Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
> This should be enhanced to support application scoped expressions:
> ${this:aProperty}
> It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
> Then you could deploy the same Message Driven Bean multiple times with a different name:
> myMDB1.ear
> myMDB2.ear
> having
> <activation-config-property-value>${this:queuename}</activation-config-property-value>
> and define
> <application-properties>
> <application name="myMDB_DEV_QUEUE_1.ear">
> <property name="queuename" value="DEV_QUEUE_1"/>
> </application>
> <application name="myMDB_DEV_QUEUE_2.ear">
> <property name="queuename" value="DEV_QUEUE_2"/>
> </application>
> </application-properties>
> whereas for production the queuename properties would be different.
> [1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-336) Ability for Deployment Overlays to overlay System Properties
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-336?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFCORE-336.
-------------------------------------
Resolution: Won't Do
I'm resolving this as Won't Do because the existing META-INF/jboss-properties facility allows deployment-specific resolution of values. A system property is globally scoped so there is no way to have it have a different value in a different context.
There are other things to track though that may meet the use case:
1) The Microprofile Config API and an impl of that that [~jmesnil] developed for use in WildFly-based servers (particularly WildFly Swarm):
https://github.com/wildfly-extras/wildfly-microprofile-config
2) A recent request for a different way to configure per deployment properties for use in expression resolution:
https://issues.jboss.org/browse/WFLY-8868
> Ability for Deployment Overlays to overlay System Properties
> ------------------------------------------------------------
>
> Key: WFCORE-336
> URL: https://issues.jboss.org/browse/WFCORE-336
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Joshua Henn
>
> Currently Deployment Overlays allow only the replacing whole resource files. It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.
> ie.
> {code:xml}
> <deployment-overlays>
> <deployment-overlay name="myOverlay">
> <system-properties>
> <property name="datasource" value="java:jboss/datasources/controller"/>
> </system-properties>
> <deployment name="controller.war"/>
> </deployment-overlay>
> </deployment-overlays>
> {code}
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8868) per application Expressions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8868?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-8868:
--------------------------------------
Component/s: EE
Assignee: (was: Jason Greene)
> per application Expressions
> ---------------------------
>
> Key: WFLY-8868
> URL: https://issues.jboss.org/browse/WFLY-8868
> Project: WildFly
> Issue Type: Feature Request
> Components: EE
> Reporter: Juergen Weber
>
> Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
> This should be enhanced to support application scoped expressions:
> ${this:aProperty}
> It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
> Then you could deploy the same Message Driven Bean multiple times with a different name:
> myMDB1.ear
> myMDB2.ear
> having
> <activation-config-property-value>${this:queuename}</activation-config-property-value>
> and define
> <application-properties>
> <application name="myMDB_DEV_QUEUE_1.ear">
> <property name="queuename" value="DEV_QUEUE_1"/>
> </application>
> <application name="myMDB_DEV_QUEUE_2.ear">
> <property name="queuename" value="DEV_QUEUE_2"/>
> </application>
> </application-properties>
> whereas for production the queuename properties would be different.
> [1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2908) Per application Expressions driven by the management model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2908?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2908:
-------------------------------------
Description:
This is the core side part of WFLY-8868. The overall request involves being able to include a properties attribute as part of a management model deployment resource, with those properties then being available to expression resolution, the same way env vars, system props, vault values and META-INF/jboss-properties values are. The core side aspect of this is to maintain the props in the model and make those values available to the DeploymentUnitProcessors. The WildFly full side part is to enhance the existing ee subsystem DUPs that deal with expression resolution to have them take advantage of this new source of resolution data.
This basically is an improvement on the existing META-INF/jboss-properties facility by allowing the admin to control the resolution without having to mess with the deployment content.
was:
Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
This should be enhanced to support application scoped expressions:
${this:aProperty}
It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
Then you could deploy the same Message Driven Bean multiple times with a different name:
myMDB1.ear
myMDB2.ear
having
<activation-config-property-value>${this:queuename}</activation-config-property-value>
and define
<application-properties>
<application name="myMDB_DEV_QUEUE_1.ear">
<property name="queuename" value="DEV_QUEUE_1"/>
</application>
<application name="myMDB_DEV_QUEUE_2.ear">
<property name="queuename" value="DEV_QUEUE_2"/>
</application>
</application-properties>
whereas for production the queuename properties would be different.
[1] https://docs.jboss.org/author/display/WFLY10/Expressions
> Per application Expressions driven by the management model
> ----------------------------------------------------------
>
> Key: WFCORE-2908
> URL: https://issues.jboss.org/browse/WFCORE-2908
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Juergen Weber
>
> This is the core side part of WFLY-8868. The overall request involves being able to include a properties attribute as part of a management model deployment resource, with those properties then being available to expression resolution, the same way env vars, system props, vault values and META-INF/jboss-properties values are. The core side aspect of this is to maintain the props in the model and make those values available to the DeploymentUnitProcessors. The WildFly full side part is to enhance the existing ee subsystem DUPs that deal with expression resolution to have them take advantage of this new source of resolution data.
> This basically is an improvement on the existing META-INF/jboss-properties facility by allowing the admin to control the resolution without having to mess with the deployment content.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months