[JBoss JIRA] (ELY-1439) Perform certificate authentication only in cases when certificate is present
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1439?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1439:
------------------------------
Component/s: SSL
> Perform certificate authentication only in cases when certificate is present
> ----------------------------------------------------------------------------
>
> Key: ELY-1439
> URL: https://issues.jboss.org/browse/ELY-1439
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Mechanisms, SSL
> Affects Versions: 1.2.0.Beta9
> Reporter: Martin Choma
>
> {panel}
> Martin Choma·10:18 AM
> I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success?
> Darran Lofthouse·11:03 AM
> @MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level. In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling. Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available.
> Martin Choma·11:09 AM
> @DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA.
> Darran Lofthouse·11:10 AM
> @MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists
> {panel}
> {noformat}
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
> 10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192]
> 10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response
> 10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service
> 10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote
> 10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient@286a43a6->org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient@149c06be->org.wildfly.security.sasl.anonymous.AnonymousSaslClient@56ad35c9] for mechanisms [ANONYMOUS]
> 10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS
> 10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
> 10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication@4dff2604
> 10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
> 10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
> 10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51)
> at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61)
> at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52)
> at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1131)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote'
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@2a8e9ff7->org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer@493accbb->org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1@6a9c91e2->org.wildfly.security.sasl.anonymous.AnonymousSaslServer@2b612585] for mechanism [ANONYMOUS]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-26) [Artemis 2.x Upgrade] MDB doesn't find its source queue when useJndi property is set to false
by Martin Švehla (JIRA)
[ https://issues.jboss.org/browse/WFWIP-26?page=com.atlassian.jira.plugin.s... ]
Martin Švehla commented on WFWIP-26:
------------------------------------
Confirming that this fixed the issue with connecting to HornetQ described in the duplicated issue WFWIP-84
> [Artemis 2.x Upgrade] MDB doesn't find its source queue when useJndi property is set to false
> ---------------------------------------------------------------------------------------------
>
> Key: WFWIP-26
> URL: https://issues.jboss.org/browse/WFWIP-26
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Martin Styk
> Assignee: Justin Bertram
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Having a MDB configured as follows:
> {code}
> @MessageDriven(name = "mdb",
> activationConfig = {
> @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
> @ActivationConfigProperty(propertyName = "destination", propertyValue ="InQueue"),
> @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"),
> })
> {code}
> MDB is not able to receive messages from InQueue.
> Server logs:
> {noformat}
> 09:53:29,128 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:29,188 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "Mdb.jar" (runtime-name : "Mdb.jar")
> 09:53:29,306 INFO [org.wildfly.naming] (default task-1) WildFly Naming version 1.0.7.Final
> 09:53:29,364 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151000: awaiting topic/queue creation jms/queue/InQueue
> 09:53:31,366 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151001: Attempting to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@2bd07716 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15)
> 09:53:31,368 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:33,480 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:35,092 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout.
> {noformat}
> In {{ActiveMQActivation.setup()}}, call to {{setupDestination()}} is made. Destiantion InQueue is instantiated there. However, during the {{ActiveMQMessageHandler.setup()}} call. consumer can not be created for this destination and exception {{AMQ119017: Queue InQueue does not exist}} is being thrown.
> {code:title=ActiveMQActivation.setup()}
> protected synchronized void setup() throws Exception {
> logger.debug("Setting up " + spec);
> setupCF();
> setupDestination();
> Exception firstException = null;
> for (int i = 0; i < spec.getMaxSession(); i++) {
> ClientSessionFactory cf = null;
> ClientSession session = null;
> try {
> cf = factory.getServerLocator().createSessionFactory();
> session = setupSession(cf);
> ActiveMQMessageHandler handler = new ActiveMQMessageHandler(factory, this, ra.getTM(), (ClientSessionInternal) session, cf, i);
> handler.setup();
> handlers.add(handler);
> } catch (Exception e) {
> ...
> }
> }
> ...
> }
> {code}
> This is regression against Artemis 1.5.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstream master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SWSQE-378) Random TAG is being generated on deploying from kiali/kiali
by Hayk Hovsepyan (JIRA)
[ https://issues.jboss.org/browse/SWSQE-378?page=com.atlassian.jira.plugin.... ]
Hayk Hovsepyan edited comment on SWSQE-378 at 8/17/18 2:36 AM:
---------------------------------------------------------------
You removed the logic of not adding random on "latest" tag, it should be back.
Also, what is the reason of this logic? will UUID be provided as env variable as it is generated in if above?
{code}
if [ "${DOCKER_REPO}" == "docker.io/kiali/kiali" ]; then
DOCKER_TAG="${DOCKER_TAG}${UUID}"
fi
{code}
was (Author: hhovsepy):
You removed the logic of not adding random on "latest" tag, it should be back.
Also, what is the reason of this logic? will UUID be provided as env variable as it is generated in if above?
if [ "${DOCKER_REPO}" == "docker.io/kiali/kiali" ]; then
DOCKER_TAG="${DOCKER_TAG}${UUID}"
fi
> Random TAG is being generated on deploying from kiali/kiali
> -----------------------------------------------------------
>
> Key: SWSQE-378
> URL: https://issues.jboss.org/browse/SWSQE-378
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Guilherme Baufaker Rêgo
> Assignee: Hayk Hovsepyan
>
> The random tag was included because the images weren't been overridden, but when we are deploying from "kiali/kiali" the exactly tag should be matched
> Example: Using Docker tag v0.6.0YWZk from Docker Repo docker.io/kiali/kiali from (http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-on-Openshi...)
> YWZk is the random component.
> This need to be switched when are using kialiqe/kiali
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4043) Issues accessing JNLP application in Internet Explorer due to missing mime-type.
by Saisha Naik (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4043?page=com.atlassian.jira.plugi... ]
Saisha Naik updated WFCORE-4043:
--------------------------------
Description:
Issues accessing a JNLP application in Internet Explorer due to missing JNLP extension in undertow. The JNLP application is rendered as an XML file due to incorrect mime-type.
This works fine in Mozilla and Chrome.
The JNLP mapping does not exist in [Mimemappings.java|https://github.com/undertow-io/undertow/blob/master/cor...].
was:
Issues accessing a JNLP application in Internet Explorer due to missing JNLP extension in undertow. The JNLP application is rendered as an XML file due to incorrect mime-type.
The JNLP mapping does not exist in [Mimemappings.java|https://github.com/undertow-io/undertow/blob/master/cor...]. The work around is to add the mime-type to the servlet container[2] :
{code}
/subsystem=undertow/servlet-container=default/mime-mapping=json:add(value="application/json")
{code}
Steps to Reproduce:
1) Deploy the Test.jnlp(attached) in welcome-root folder.
2) Deploy TestJnlp.jar(attached) in deployments/ directory.
2) Access the URL : https://IP:PORT/Test.jnlp
3) It will prompt to download the Test.jnlp file. Accept and double click on it.
4) Click on the "Run" button to lauch the AWT program.
The above steps will work fine in browsers like Mozilla and Chrome, but fail in IE.
Attachment: Test.jnlp
TestJnlp.jar
Workaround Description:
The work around is to add the mime-type explicitly to the servlet container :
{code}
/subsystem=undertow/servlet-container=default/mime-mapping=json:add(value="application/json")
{code}
Workaround: Workaround Exists
Affects: Migration,Compatibility/Configuration,User Experience
> Issues accessing JNLP application in Internet Explorer due to missing mime-type.
> --------------------------------------------------------------------------------
>
> Key: WFCORE-4043
> URL: https://issues.jboss.org/browse/WFCORE-4043
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Saisha Naik
> Priority: Minor
> Attachments: Test.jnlp, TestJnlp.jar
>
>
> Issues accessing a JNLP application in Internet Explorer due to missing JNLP extension in undertow. The JNLP application is rendered as an XML file due to incorrect mime-type.
> This works fine in Mozilla and Chrome.
> The JNLP mapping does not exist in [Mimemappings.java|https://github.com/undertow-io/undertow/blob/master/cor...].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1639) FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1639?page=com.atlassian.jira.plugin.s... ]
Martin Choma edited comment on ELY-1639 at 8/17/18 2:01 AM:
------------------------------------------------------------
Thank you very much. Couple of notes after first look:
* provider="SunPKCS11-testPkcs" is not necessary, right?
* Now we have different approaches for configuring key-manager (with keystore reference) and trust-manager (without keystore reference). I personally like more key-manager style. As it is how *-managers on server-side are configured as well. So basically leaving trustmanager approach only different. So ideally in future trust-manager could have also reference to trust-store. And we can deprecate trust-store resource.
* So If I understand correctly key-store-ssl-certificate is left as is. If key-store-ssl-certificate is used Custom KeyManager is used. We need to document this difference in client scheme.
* -on key-manager is it possible to configure provider?-
* I dont see the way of specifying password (key password) on key-manager element. Both server side key-manager and key-store-ssl-certificate have it
was (Author: mchoma):
Thank you very much. Couple of notes after first look:
* provider="SunPKCS11-testPkcs" is not necessary, right?
* Now we have different approaches for configuring key-manager (with keystore reference) and trust-manager (without keystore reference). I personally like more key-manager style. As it is how *-managers on server-side are configured as well. So basically leaving trustmanager approach only different. So ideally in future trust-manager could have also reference to trust-store. And we can deprecate trust-store resource.
* So If I understand correctly key-store-ssl-certificate is left as is. If key-store-ssl-certificate is used Custom KeyManager is used. We need to document this difference in client scheme.
* - on key-manager is it possible to configure provider?-
* I dont see the way of specifying password (key password) on key-manager element. Both server side key-manager and key-store-ssl-certificate have it
> FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
> -------------------------------------------------------------
>
> Key: ELY-1639
> URL: https://issues.jboss.org/browse/ELY-1639
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: cli-wildfly-config.xml
>
>
> Fix of ELY-1622 introduced regression. It is not possible to do 1 way ssl (no key-store-ssl-certificate in wildfly-config.xml) with exception
> {code}
> 14:13:56,143 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> ... 5 more
> Caused by: java.io.IOException: Failed to obtain SSLContext
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> ... 8 more
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
> ... 10 more
> {code}
> It is because after fix Fix of ELY-1622 custom keymanager is used. But it is forbidden by jdk FIPS PKCS11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months