[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero edited comment on WFCORE-944 at 6/19/20 10:39 AM:
--------------------------------------------------------------------------
I stumbled on this a few days ago working on another JIRA. I implemented not long ago a PKCS12 test [HTTPSManagementInterfacePKCS12TestCase.java|https://github.com/wildfly/wildfly-core/blob/master/testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfacePKCS12TestCase.java] and I think it's easy to complete that test to also set the keystore-provider to all the keystores and test Darran's fix. I'll provide a new PR the next week.
was (Author: rhn-support-rmartinc):
I stumbled into this a few days ago working on another JIRA. I implemented not long ago a PKCS12 test [HTTPSManagementInterfacePKCS12TestCase.java|https://github.com/wildfly/wildfly-core/blob/master/testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfacePKCS12TestCase.java] and I think it's easy to complete that test to also set the keystore-provider to all the keystores and test Darran's fix. I'll provide a new PR the next week.
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.redhat.com/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero commented on WFCORE-944:
------------------------------------------------
I stumbled into this a few days ago working on another JIRA. I implemented not long ago a PKCS12 test [HTTPSManagementInterfacePKCS12TestCase.java|https://github.com/wildfly/wildfly-core/blob/master/testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfacePKCS12TestCase.java] and I think it's easy to complete that test to also set the keystore-provider to all the keystores and test Darran's fix. I'll provide a new PR the next week.
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.redhat.com/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13354) Add Galleon layers for the EJB subsystem
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13354?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13354:
-----------------------------------------
FYI I don't think it should impact this specific task but I have recently been working on trying to convert some external projects to use slimmed servers provisioned by Galleon.
At the moment it appears the correct handling of JACC permissions for a deployment depends upon the legacy security subsystem, this has not been very noticeable as ejb3 was not in a layer so the whole feature pack needed to be provisioned but once the ejb3 subsystem is in a layer it will make it easier to provision without legacy security.
> Add Galleon layers for the EJB subsystem
> ----------------------------------------
>
> Key: WFLY-13354
> URL: https://issues.redhat.com/browse/WFLY-13354
> Project: WildFly
> Issue Type: Feature Request
> Components: Build System, EJB
> Reporter: Brian Stansberry
> Assignee: Cheng Fang
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero reassigned WFCORE-944:
----------------------------------------------
Assignee: Ricardo Martin Camarero
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.redhat.com/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (ELY-1998) IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11
by Diana Vilkolakova (Jira)
[ https://issues.redhat.com/browse/ELY-1998?page=com.atlassian.jira.plugin.... ]
Diana Vilkolakova commented on ELY-1998:
----------------------------------------
[~rlucente-se-jboss] Do you by any chance have some experience with FIPS BC configuration on JDK11 ? Is it possible to setup default SecureRandom in java.security file?
> IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1998
> URL: https://issues.redhat.com/browse/ELY-1998
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Diana Vilkolakova
> Priority: Major
>
> The below steps require ELY-1982 bugfix to work.
> Configure security providers in java.security file:
> {code}
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
> security.provider.3=SUN
> {code}
> Add the bc-fips.jar and bctls-fips-1.0.10.jar to the CLASSPATH and generate keystore in JBOSS_HOME/standalone/configuration folder:
> {code}
> keytool -genkeypair -alias appserver -keyalg RSA -keysize 2048 -keypass password -keystore "fips.keystore" -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -providerpath $CLASSPATH -storetype BCFKS -storepass password -dname "CN=testserver,OU=TESTOU,O=TESTO,L=TESTL,ST=TESTCZ,C=TESTCZ" -validity 730 -v
> {code}
> Try to configure `server-ssl-context`:
> {code}
> module add --name=org.bouncycastle.fips --resources=/path/to/bc-fips-1.0.2.jar:/path/to/bctls-fips-1.0.10.jar
> /subsystem=elytron/provider-loader=bc:add(module=org.bouncycastle.fips)
> /subsystem=elytron/key-store=fipsKS:add(path=fips.keystore, relative-to=jboss.server.config.dir, credential-reference={clear-text=password}, type="BCFKS", providers=bc)
> /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS, algorithm="X509", credential-reference={clear-text=password}, providers=bc)
> /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM, protocols=["TLSv1.2"], providers=bc)
> {code}
> The last command results in:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.fipsSSC" => "Failed to start service
> Caused by: java.lang.IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available
> Caused by: java.security.NoSuchAlgorithmException: DEFAULT SecureRandom not available"}},
> "rolled-back" => true
> }
> {code}
> The exception is happening [on this line|https://github.com/Skyllarr/wildfly-elytron/blob/ELY-1982/ssl/src/ma...] . This exception can be avoided by either using *new SecureRandom()* instead of null during initialization of sslContext, or by configuring securerandom with using *CryptoServicesRegistrar.setSecureRandom(new SecureRandom());* in code beforehand (this would require bc dependency).
> I tried to configure secure random statically by setting *securerandom.strongAlgorithms=DEFAULT:BCFIPS* in java.security or by trying to pass secure random as parameter to constructor with
> {code}
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider "C:DEFRND[SHA512];ENABLE{ALL};"
> {code}
> but neither had any effect. I did not find how to configure this statically for Java 11 in BC documentation.
> We could pass new instance of SecureRandom when initializing sslContext (if bouncycastle is used), or set secureRandom beforehand, or catch this exception and then use `new SecureRandom()`. But should we force the users to use SecureRandom set in the code by us? If users want to use Bouncycastle they should configure the secure random themselves since it is needed by the provider?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-5291) Import of empty scesim file leads to Unexpected error
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5291?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5291:
-------------------------------
Sprint: 2020 Week 25-27 (from Jun 15)
> Import of empty scesim file leads to Unexpected error
> -----------------------------------------------------
>
> Key: DROOLS-5291
> URL: https://issues.redhat.com/browse/DROOLS-5291
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.40.0.Final
>
> Attachments: Traffic.zip, errorlog.txt, image-2020-04-17-16-47-29-261.png, image-2020-04-17-16-47-32-047.png
>
>
> If user generate a scesim file using vs code extention it is not comparable with BC.
> Use Vscode generated files [^Traffic.zip]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13599) Admin console will not open - I added users
by Harald Pehl (Jira)
[ https://issues.redhat.com/browse/WFLY-13599?page=com.atlassian.jira.plugi... ]
Harald Pehl resolved WFLY-13599.
--------------------------------
Resolution: Explained
> Admin console will not open - I added users
> -------------------------------------------
>
> Key: WFLY-13599
> URL: https://issues.redhat.com/browse/WFLY-13599
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 18.0.1.Final, 20.0.0.Final
> Reporter: Charles Herrick
> Assignee: Harald Pehl
> Priority: Major
>
> Wildfly 18.0.1 final and Wildfly 20.0 final installed.
> add-user.bat executed for admin and one other user.
> Kie-server 7.38 war deployed to deployments. start server.
> Admin console will not display. Error says "you have not yet added users".
> Used: add-user -a -u admin -p **** -ro admin,kie-server,rest-all,kiemgmt
> Got: Updated user 'admin' to file 'C:\Redhat\Wildfly18\standalone\configuration\application-users.properties'
> Updated user 'admin' to file 'C:\Redhat\Wildfly18\domain\configuration\application-users.properties'
> Updated user 'admin' with groups admin,kie-server,rest-all,kiemgmt to file 'C:\Redhat\Wildfly18\standalone\configuration\application-roles.properties'
> Updated user 'admin' with groups admin,kie-server,rest-all,kiemgmt to file 'C:\Redhat\Wildfly18\domain\configuration\application-roles.properties'
>
> Please help me get the admin console up.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13599) Admin console will not open - I added users
by Harald Pehl (Jira)
[ https://issues.redhat.com/browse/WFLY-13599?page=com.atlassian.jira.plugi... ]
Harald Pehl edited comment on WFLY-13599 at 6/19/20 6:14 AM:
-------------------------------------------------------------
You have to add a management user to access the admin console. Please don't use the {{-a}} option, which adds an _application user_:
{code:java}
bin/add-user.sh -u admin -p admin -ro admin,kie-server,rest-all,kiemgmt {code}
Now you should be able to access the admin in console using admin/admin.
was (Author: harald.pehl):
You have to add a management user to access the admin console. Please don't use the {{-a}} option when adding the admin user:
{code:java}
bin/add-user.sh -u admin -p admin -ro admin,kie-server,rest-all,kiemgmt {code}
Now you should be able to access the admin in console using admin/admin.
> Admin console will not open - I added users
> -------------------------------------------
>
> Key: WFLY-13599
> URL: https://issues.redhat.com/browse/WFLY-13599
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 18.0.1.Final, 20.0.0.Final
> Reporter: Charles Herrick
> Assignee: Harald Pehl
> Priority: Major
>
> Wildfly 18.0.1 final and Wildfly 20.0 final installed.
> add-user.bat executed for admin and one other user.
> Kie-server 7.38 war deployed to deployments. start server.
> Admin console will not display. Error says "you have not yet added users".
> Used: add-user -a -u admin -p **** -ro admin,kie-server,rest-all,kiemgmt
> Got: Updated user 'admin' to file 'C:\Redhat\Wildfly18\standalone\configuration\application-users.properties'
> Updated user 'admin' to file 'C:\Redhat\Wildfly18\domain\configuration\application-users.properties'
> Updated user 'admin' with groups admin,kie-server,rest-all,kiemgmt to file 'C:\Redhat\Wildfly18\standalone\configuration\application-roles.properties'
> Updated user 'admin' with groups admin,kie-server,rest-all,kiemgmt to file 'C:\Redhat\Wildfly18\domain\configuration\application-roles.properties'
>
> Please help me get the admin console up.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13599) Admin console will not open - I added users
by Harald Pehl (Jira)
[ https://issues.redhat.com/browse/WFLY-13599?page=com.atlassian.jira.plugi... ]
Harald Pehl edited comment on WFLY-13599 at 6/19/20 6:13 AM:
-------------------------------------------------------------
You have to add a management user to access the admin console. Please don't use the {{-a}} option when adding the admin user:
{code:java}
bin/add-user.sh -u admin -p admin -ro admin,kie-server,rest-all,kiemgmt {code}
Now you should be able to access the admin in console using admin/admin.
was (Author: harald.pehl):
I wasn't able to reproduce the error.
Here are my steps:
# Download clean WildFly 20.0.0.Final
# {{bin/add-user.sh -a -u admin -p admin -ro admin,kie-server,rest-all,kiemgmt}}
# {{bin/standalone.sh}}
# Open [http://localhost:9990|http://localhost:9990/]
# Login with admin/admin
Did I miss anything?
> Admin console will not open - I added users
> -------------------------------------------
>
> Key: WFLY-13599
> URL: https://issues.redhat.com/browse/WFLY-13599
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 18.0.1.Final, 20.0.0.Final
> Reporter: Charles Herrick
> Assignee: Harald Pehl
> Priority: Major
>
> Wildfly 18.0.1 final and Wildfly 20.0 final installed.
> add-user.bat executed for admin and one other user.
> Kie-server 7.38 war deployed to deployments. start server.
> Admin console will not display. Error says "you have not yet added users".
> Used: add-user -a -u admin -p **** -ro admin,kie-server,rest-all,kiemgmt
> Got: Updated user 'admin' to file 'C:\Redhat\Wildfly18\standalone\configuration\application-users.properties'
> Updated user 'admin' to file 'C:\Redhat\Wildfly18\domain\configuration\application-users.properties'
> Updated user 'admin' with groups admin,kie-server,rest-all,kiemgmt to file 'C:\Redhat\Wildfly18\standalone\configuration\application-roles.properties'
> Updated user 'admin' with groups admin,kie-server,rest-all,kiemgmt to file 'C:\Redhat\Wildfly18\domain\configuration\application-roles.properties'
>
> Please help me get the admin console up.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months