[JBoss JIRA] (WFCORE-2199) RuntimeExpressionResolver does not fail upon seeing a vault expression if no VaultReader is present
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2199?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2199:
------------------------------------------
We can't test WFCORE-2199 without a fix for the testsuite problem WFCORE-2198 aims at. I originally tried to fix it as part of WFCORE-2182 but the testsuite won't pass with the change because it has tests that assume a vault expression will resolve, not realizing that with PicketBox not in place they do resolve, but not correctly. The tests are not concerned with correct resolution, just whether RBAC allows the ops to succeed or fail, and this change will make the ops fail for non-RBAC reasons. See VaultExpressionSensitivityTestCase.
> RuntimeExpressionResolver does not fail upon seeing a vault expression if no VaultReader is present
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2199
> URL: https://issues.jboss.org/browse/WFCORE-2199
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> If the server is unable to instantiate RuntimeVaultReader, which will be the case for the WildFly Core dist as it doesn't package the org.picketbox module needed by RuntimeVaultReader, then RuntimeExpressionResolver will ignore vault expressions, allowing the superclass to take over and process them. This will be done incorrectly, as the superclass will treat the first ':' in the vault expression as the delimiter between a system property name and the default value, resolving the expression to everything after that first ':'. So
> ${VAULT::datasources::password::123AB45CD}
> resolves to
> :datasources::password::123AB45CD
> Minor as the resolved value is unlikely to be useful, so there will be a failure.
> Possibly could be treated as an Enhancement.
> Fix would be for RuntimeExpressionResolver to check for the vault expression pattern and throw NoSuchItemException if found and not VaultReader is available.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2199) RuntimeExpressionResolver does not fail upon seeing a vault expression if no VaultReader is present
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2199?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2199:
-------------------------------------
Description:
If the server is unable to instantiate RuntimeVaultReader, which will be the case for the WildFly Core dist as it doesn't package the org.picketbox module needed by RuntimeVaultReader, then RuntimeExpressionResolver will ignore vault expressions, allowing the superclass to take over and process them. This will be done incorrectly, as the superclass will treat the first ':' in the vault expression as the delimiter between a system property name and the default value, resolving the expression to everything after that first ':'. So
{code}
${VAULT::datasources::password::123AB45CD}
{code}
resolves to
{code}
:datasources::password::123AB45CD
{code}
Minor as the resolved value is unlikely to be useful, so there will be a failure.
Possibly could be treated as an Enhancement.
Fix would be for RuntimeExpressionResolver to check for the vault expression pattern and throw NoSuchItemException if found and not VaultReader is available.
was:
If the server is unable to instantiate RuntimeVaultReader, which will be the case for the WildFly Core dist as it doesn't package the org.picketbox module needed by RuntimeVaultReader, then RuntimeExpressionResolver will ignore vault expressions, allowing the superclass to take over and process them. This will be done incorrectly, as the superclass will treat the first ':' in the vault expression as the delimiter between a system property name and the default value, resolving the expression to everything after that first ':'. So
${VAULT::datasources::password::123AB45CD}
resolves to
:datasources::password::123AB45CD
Minor as the resolved value is unlikely to be useful, so there will be a failure.
Possibly could be treated as an Enhancement.
Fix would be for RuntimeExpressionResolver to check for the vault expression pattern and throw NoSuchItemException if found and not VaultReader is available.
> RuntimeExpressionResolver does not fail upon seeing a vault expression if no VaultReader is present
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2199
> URL: https://issues.jboss.org/browse/WFCORE-2199
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> If the server is unable to instantiate RuntimeVaultReader, which will be the case for the WildFly Core dist as it doesn't package the org.picketbox module needed by RuntimeVaultReader, then RuntimeExpressionResolver will ignore vault expressions, allowing the superclass to take over and process them. This will be done incorrectly, as the superclass will treat the first ':' in the vault expression as the delimiter between a system property name and the default value, resolving the expression to everything after that first ':'. So
> {code}
> ${VAULT::datasources::password::123AB45CD}
> {code}
> resolves to
> {code}
> :datasources::password::123AB45CD
> {code}
> Minor as the resolved value is unlikely to be useful, so there will be a failure.
> Possibly could be treated as an Enhancement.
> Fix would be for RuntimeExpressionResolver to check for the vault expression pattern and throw NoSuchItemException if found and not VaultReader is available.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2199) RuntimeExpressionResolver does not fail upon seeing a vault expression if no VaultReader is present
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2199:
----------------------------------------
Summary: RuntimeExpressionResolver does not fail upon seeing a vault expression if no VaultReader is present
Key: WFCORE-2199
URL: https://issues.jboss.org/browse/WFCORE-2199
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
If the server is unable to instantiate RuntimeVaultReader, which will be the case for the WildFly Core dist as it doesn't package the org.picketbox module needed by RuntimeVaultReader, then RuntimeExpressionResolver will ignore vault expressions, allowing the superclass to take over and process them. This will be done incorrectly, as the superclass will treat the first ':' in the vault expression as the delimiter between a system property name and the default value, resolving the expression to everything after that first ':'. So
${VAULT::datasources::password::123AB45CD}
resolves to
:datasources::password::123AB45CD
Minor as the resolved value is unlikely to be useful, so there will be a failure.
Possibly could be treated as an Enhancement.
Fix would be for RuntimeExpressionResolver to check for the vault expression pattern and throw NoSuchItemException if found and not VaultReader is available.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2198) Create a picketbox feature pack
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2198:
----------------------------------------
Summary: Create a picketbox feature pack
Key: WFCORE-2198
URL: https://issues.jboss.org/browse/WFCORE-2198
Project: WildFly Core
Issue Type: Task
Reporter: Brian Stansberry
We should add a picketbox feature pack to WildFly Core, not included in the dist but built there.
Background:
We include PicketBox in the core pom and the vault functionality core provides requires it but we are not willing to include it in the core dist because it adds ~ 1MB to the dist size.
However, the way we are handling the picketbox module is not clean. The version of two of the jars that end up in the module are declared in the core pom.xml (as they are needed at compile time by core) but the 3rd is specified in full's pom.xml and the module.xml is in full.
We need an org.picketbox module in place to properly test core's vault handling in testsuite/rbac and testsuite/manualmode and there's no real good way to get it into the installations used by those testsuites
Option:
Just add the feature pack maven module as a child of the testsuite maven module, limiting the feature pack use to the testsuite, which is the primary driver of me filing this. That removes any implied requirement to maintain it beyond the needs of the testsuite or to include jars in the generated module beyond what the testsuite needs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-879) Authentication against HTTP management interface with empty username causes Internal Server Error (status 500)
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-879?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse moved WFCORE-2162 to ELY-879:
----------------------------------------------
Project: WildFly Elytron (was: WildFly Core)
Key: ELY-879 (was: WFCORE-2162)
Component/s: HTTP
(was: Security)
Fix Version/s: 1.1.0.Beta20
(was: 3.0.0.Alpha20)
> Authentication against HTTP management interface with empty username causes Internal Server Error (status 500)
> --------------------------------------------------------------------------------------------------------------
>
> Key: ELY-879
> URL: https://issues.jboss.org/browse/ELY-879
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta20
>
>
> In case when empty username is passed during authentication to Management Console then exception is thrown to server log and Internal Server Error (status 500) is returned to user (which leads to displaying "Connect to Management Interface" page. User is not able to try to login again.
> In WildFly 10.1.0 this scenario works fine - after passing empty username during authentication, authentication failed and login window is displayed again. I request blocker due to regression.
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (management task-3) UT005071: Undertow request failed HttpServerExchange{ GET /management request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate], User-Agent=[Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0], Connection=[keep-alive], Authorization=[Digest username="", realm="ManagementRealm", nonce="AAAAAwAAAlzTPVPLC0qPi6CaEhTCHZa+QjsuAjn3OsQXcuDYAxrOtc+rRMs=", uri="/management", algorithm=MD5, response="cbd764e6c09577625476340f7bcfc84d", opaque="00000000000000000000000000000000"], Content-Type=[text/plain; charset=utf-8], Cookie=[__utma=111872281.1874867570.1477040206.1479886566.1479982414.11; __utmz=111872281.1477040206.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=111872281.5.10.1479982414; __utmt=1; __utmc=111872281], Referer=[http://localhost:9990/console/App.html], Host=[localhost:9990]} response {X-Frame-Options=[SAMEORIGIN]}}: java.lang.IllegalArgumentException
> at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.getH_A1(DigestAuthenticationMechanism.java:233)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.validateResponse(DigestAuthenticationMechanism.java:189)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.evaluateRequest(DigestAuthenticationMechanism.java:121)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 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:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-879) HTTP Digest mechanism not checking length of username causing IllegalArgument Exception
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-879?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-879:
---------------------------------
Summary: HTTP Digest mechanism not checking length of username causing IllegalArgument Exception (was: Authentication against HTTP management interface with empty username causes Internal Server Error (status 500))
> HTTP Digest mechanism not checking length of username causing IllegalArgument Exception
> ---------------------------------------------------------------------------------------
>
> Key: ELY-879
> URL: https://issues.jboss.org/browse/ELY-879
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta20
>
>
> In case when empty username is passed during authentication to Management Console then exception is thrown to server log and Internal Server Error (status 500) is returned to user (which leads to displaying "Connect to Management Interface" page. User is not able to try to login again.
> In WildFly 10.1.0 this scenario works fine - after passing empty username during authentication, authentication failed and login window is displayed again. I request blocker due to regression.
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (management task-3) UT005071: Undertow request failed HttpServerExchange{ GET /management request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate], User-Agent=[Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0], Connection=[keep-alive], Authorization=[Digest username="", realm="ManagementRealm", nonce="AAAAAwAAAlzTPVPLC0qPi6CaEhTCHZa+QjsuAjn3OsQXcuDYAxrOtc+rRMs=", uri="/management", algorithm=MD5, response="cbd764e6c09577625476340f7bcfc84d", opaque="00000000000000000000000000000000"], Content-Type=[text/plain; charset=utf-8], Cookie=[__utma=111872281.1874867570.1477040206.1479886566.1479982414.11; __utmz=111872281.1477040206.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=111872281.5.10.1479982414; __utmt=1; __utmc=111872281], Referer=[http://localhost:9990/console/App.html], Host=[localhost:9990]} response {X-Frame-Options=[SAMEORIGIN]}}: java.lang.IllegalArgumentException
> at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.getH_A1(DigestAuthenticationMechanism.java:233)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.validateResponse(DigestAuthenticationMechanism.java:189)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.evaluateRequest(DigestAuthenticationMechanism.java:121)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 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:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2197) ability to upload content from secure web server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2197?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2197:
----------------------------------------
Component/s: Domain Management
Security
Assignee: Brian Stansberry (was: Jason Greene)
This will take some thought. I doubt we'd encode it in the url parameter; if the server is stripping the data out it might as well use some more formal parameters.
A simple username/password param seems a bit inelegant although it is simplest.
Fundamentally the server is connecting to an outside resource and it would be good if that were configured in a manner consistent with other ways it connects with outside resources. The url param then just drives what set of configuration it uses.
> ability to upload content from secure web server
> ------------------------------------------------
>
> Key: WFCORE-2197
> URL: https://issues.jboss.org/browse/WFCORE-2197
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Ian Kent
> Assignee: Brian Stansberry
>
> We use the upload-deployment-url operation of wildfly management API to add content to content repository (app war) from remote web server (nexus artifact repository manager). As the nexus web server is secure so the wildfly app server needs to pass credentials to nexus when downloading war to wildfly content repository for deployment. Is there a way to encode the nexus username and password in url parameter or add a additional parameters for username and password.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2197) ability to upload content from secure web server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2197?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-7891 to WFCORE-2197:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2197 (was: WFLY-7891)
Affects Version/s: (was: 8.2.0.Final)
> ability to upload content from secure web server
> ------------------------------------------------
>
> Key: WFCORE-2197
> URL: https://issues.jboss.org/browse/WFCORE-2197
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Ian Kent
> Assignee: Jason Greene
>
> We use the upload-deployment-url operation of wildfly management API to add content to content repository (app war) from remote web server (nexus artifact repository manager). As the nexus web server is secure so the wildfly app server needs to pass credentials to nexus when downloading war to wildfly content repository for deployment. Is there a way to encode the nexus username and password in url parameter or add a additional parameters for username and password.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-427) CLI doesn't read alias from .jbossclirc
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-427?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFCORE-427:
---------------------------------------------
This used to be not possible to fix due to alias being handled by aesh console and other commands/operations being handled by CLI.
In the redesign we are doing when moving to use aesh-readline, the CLI, in non interactive mode, first call into aesh-readline to:
1) handle builtin commands (such as alias)
2) parse the line (in case some aliases are to be replaced).
> CLI doesn't read alias from .jbossclirc
> ---------------------------------------
>
> Key: WFCORE-427
> URL: https://issues.jboss.org/browse/WFCORE-427
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Osamu Nagano
> Assignee: Jean-Francois Denise
>
> By WFLY-1063, a variable can be defined in .jbossclirc and preloaded by CLI. But aliases are not able to define with {{org.jboss.as.cli.CliInitializationException}}.
> {code}
> $ cat .jbossclirc
> set prod_db=/subsystem=datasources/data-source=ExampleDS
> alias ll=ls -l
> $ $JBOSS_HOME/bin/jboss-cli.sh -c
> Unexpected command 'alias ll=ls -l'. Type 'help --commands' for the list of supported commands.
> org.jboss.as.cli.CliInitializationException: Failed to process /home/onagano/cases/01180422/wf810/.jbossclirc
> at org.jboss.as.cli.impl.CliLauncher.runcom(CliLauncher.java:352)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:305)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> {code}
> Enclosing by single quote or double quote won't help.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-644:
------------------------------
Fix Version/s: 3.0.0.Alpha20
(was: 3.0.0.Alpha19)
> jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-644
> URL: https://issues.jboss.org/browse/WFCORE-644
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha20
>
>
> The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file.
> This is problematic when the JVM is running in FIPS mode.
> The cli throws the following exception on startup:
> $ ./bin/jboss-cli.sh
> org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89)
> at javax.net.ssl.SSLContext.init(SSLContext.java:283)
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537)
> ... 11 more
> It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file:
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months