[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 …
[View More]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)
[View Less]
10 years, 3 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 …
[View More]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)
[View Less]
10 years, 3 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"…
[View More].
# 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)
[View Less]
10 years, 3 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 …
[View More]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)
[View Less]
10 years, 3 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"…
[View More].
# 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)
[View Less]
10 years, 3 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
> --------------------------…
[View More]-------------------------
>
> 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)
[View Less]
10 years, 3 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: …
[View More]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)
[View Less]
10 years, 3 months