[JBoss JIRA] (WFLY-4236) vault.bat doesn't work with JDK 9-ea
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created WFLY-4236:
----------------------------------------
Summary: vault.bat doesn't work with JDK 9-ea
Key: WFLY-4236
URL: https://issues.jboss.org/browse/WFLY-4236
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 9.0.0.Beta1
Environment: Windows 8.1, JDK 9-ea build 44
Reporter: Juergen Zimmermann
Assignee: Darran Lofthouse
I compiled the current WildFly snapshot with JDK 8u25 on Windows 8.1 box. To configure the vault (for the database password) I switched to JDK 9 (early access, build 44). Then I created a keystore which can be listed:
{code}
C:\>keytool -list -v -storetype jceks -keystore C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\standalone\configuration\vault\vault.jceks -storepass <mypwd>
Keystore-Typ: JCEKS
Keystore-Provider: SunJCE
Keystore enthält 1 Eintrag
Aliasname: vault
Erstellungsdatum: 09.01.2015
Eintragstyp: SecretKeyEntry
*******************************************
*******************************************
{code}
Then I invoked vault.bat, which was failing:
{code}
C:\>SET VAULT_DIR=C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault
C:\>vault.bat -k %VAULT_DIR%/vault.jceks -a db-pass -x p -s ABCD1234 -p <mypwd> -e %VAULT_DIR%/
=========================================================================
JBoss Vault Tool
JBOSS_HOME: "C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107"
JAVA: "C:\Zimmermann\Java\jdk\bin\java"
JAVA_OPTS: ""
=========================================================================
Problem occurred:
java.lang.Exception: WFLYSEC0045: Exception encountered:
at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:192)
at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:210)
at org.jboss.as.security.vault.VaultTool.execute(VaultTool.java:193)
at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.modules.Module.run(Module.java:308)
at org.jboss.modules.Main.main(Main.java:483)
Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210)
at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:189)
... 9 more
Caused by: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:691)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:205)
... 10 more
Caused by: java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector from [Module "org.picketbox:main" from local module loader @3e77a1ed (finder: local module finder @3ffcd140 (roots: C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules,C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules\system\layers\base))]
at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:842)
at java.security.KeyStore.load(KeyStore.java:1446)
at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:201)
at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:151)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:688)
... 11 more
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on JGRP-1905 at 1/9/15 10:12 AM:
-------------------------------------------------------------
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing in WildFly 9:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web" using channel "ee".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC via its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist for its "ee" channel, triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web" using channel "ee".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
was (Author: pferraro):
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web" using channel "ee".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC via its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist for its "ee" channel, triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web" using channel "ee".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on JGRP-1905 at 1/9/15 10:09 AM:
-------------------------------------------------------------
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web" using channel "ee".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC via its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist for its "ee" channel, triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web" using channel "ee".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
was (Author: pferraro):
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC using its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated JGRP-1905:
-------------------------------
Issue Type: Bug (was: Enhancement)
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated JGRP-1905:
-------------------------------
Priority: Critical (was: Major)
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1905:
------------------------------------
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC using its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on JGRP-1905 at 1/9/15 10:01 AM:
-------------------------------------------------------------
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC using its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
was (Author: pferraro):
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC using its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-2980) TLS client authentication configuration not working
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2980?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2980:
-----------------------------------
Guys, I cannot reproduce this. We also test this as part of our testsuite.
see for the test itself: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/manu...
I would say problem is in certificates you use and how are they generated.
> TLS client authentication configuration not working
> ---------------------------------------------------
>
> Key: WFLY-2980
> URL: https://issues.jboss.org/browse/WFLY-2980
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: dfisher
> Assignee: Tomaz Cerar
>
> Configuration of a security realm with a truststore does not result in an SSL trust manager with the appropriate certificate authorities.
> This configuration:
> {code}
> <security-realm name="HTTPSRealm">
> <server-identities>
> <ssl>
> <keystore alias="server" path="/path/to/my.keystore" keystore-password="changeit" />
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/path/to/my.truststore" keystore-password="changeit" />
> </authentication>
> </security-realm>
> {code}
> Should expose the certificates in my.truststore as accepted authorities for client authentication.
> An SSL debug shows that no authorities are configured:
> {code}
> *** CertificateRequest
> Cert Types: RSA, DSS, ECDSA
> Cert Authorities:
> <Empty>
> *** ServerHelloDone
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-2980) TLS client authentication configuration not working
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2980?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-2980.
-------------------------------
Resolution: Cannot Reproduce Bug
> TLS client authentication configuration not working
> ---------------------------------------------------
>
> Key: WFLY-2980
> URL: https://issues.jboss.org/browse/WFLY-2980
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: dfisher
> Assignee: Tomaz Cerar
>
> Configuration of a security realm with a truststore does not result in an SSL trust manager with the appropriate certificate authorities.
> This configuration:
> {code}
> <security-realm name="HTTPSRealm">
> <server-identities>
> <ssl>
> <keystore alias="server" path="/path/to/my.keystore" keystore-password="changeit" />
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/path/to/my.truststore" keystore-password="changeit" />
> </authentication>
> </security-realm>
> {code}
> Should expose the certificates in my.truststore as accepted authorities for client authentication.
> An SSL debug shows that no authorities are configured:
> {code}
> *** CertificateRequest
> Cert Types: RSA, DSS, ECDSA
> Cert Authorities:
> <Empty>
> *** ServerHelloDone
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-2893) Determine cause of unreported test failures
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2893?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-2893.
-------------------------------
Resolution: Done
This hasn't happened since, i did add few more safeguards just to make sure this doesn't happen again.
> Determine cause of unreported test failures
> -------------------------------------------
>
> Key: WFLY-2893
> URL: https://issues.jboss.org/browse/WFLY-2893
> Project: WildFly
> Issue Type: Task
> Components: Build System, Test Suite
> Affects Versions: 8.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Beta1
>
>
> Identify the reason why the failing tests that needed https://github.com/wildfly/wildfly/commit/90643bc435a9ba439cf2988e5b7407d... to get working did not fail the build. Those tests were failing for 2.5 months. Fortunately it was just a test problem, not a broken feature.
> They involved separate surefire executions. We want to avoid those, but sometimes they are needed to use different config files. We have separate executions in testsuite/integration/basic as well, covering a much broader scope, so if this kind of problem happened there as well we could have a big problem.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months