[JBoss JIRA] (ELY-1648) FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
2:33 a.m.
[
https://issues.jboss.org/browse/ELY-1648?page=com.atlassian.jira.plugin.s...
]
Martin Choma updated ELY-1648:
------------------------------
Steps to Reproduce:
- Run server and jboss-cli client with FIPS java
- ./jboss-cli.sh \
-c \
-Dwildfly.config.url=file:///home/mchoma/task/ELY-1648/wildfly-config.xml \
--connect
{code}
/subsystem=elytron/key-store=key-store-name_test-server-ssl-context:add(type=PKCS11,
credential-reference={clear-text => pass123+})
/subsystem=elytron/key-manager=key-manager-name_test-server-ssl-context:add(key-store=key-store-name_test-server-ssl-context,
credential-reference={clear-text => pass123+})
/subsystem=elytron/key-store=trust-store-name_test-server-ssl-context:add(type=PKCS11,
credential-reference={clear-text => pass123+})
/subsystem=elytron/trust-manager=trust-manager-name_test-server-ssl-context:add(key-store=trust-store-name_test-server-ssl-context)
/subsystem=elytron/server-ssl-context=test-server-ssl-context:add(key-manager=key-manager-name_test-server-ssl-context,
cipher-suite-filter="TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,TLS_ECDH_anon_WITH_AES_256_CBC_SHA",
trust-manager=trust-manager-name_test-server-ssl-context, protocols=[TLSv1.1],
need-client-auth=true)
/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context,
value=test-server-ssl-context)
reload
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding,
value=management-https)
reload
{code}
Exception thrown from CLI trying to reconnect
was:
- ./standalone.sh
- run CLI with FIPS PKCS11 java
{code}
./jboss-cli.sh \
-c \
-Dwildfly.config.url=file:///from/attachment/cli-test-wildfly-config.xml \
--connect \
:read-attribute\(name=server-state\)
{code}
FIPS NoSuchAlgorithmException: JKS KeyStore not available when
trustmanager SunX509
-----------------------------------------------------------------------------------
Key: ELY-1648
URL: https://issues.jboss.org/browse/ELY-1648
Project: WildFly Elytron
Issue Type: Bug
Components: SSL
Affects Versions: 1.5.5.Final
Reporter: Martin Choma
Assignee: Justin Cook
Attachments: java.security
With SunX509 truststore algorithm I can succesfully connect with CLI.
{code}
<configuration>
<authentication-client xmlns="urn:elytron:client:1.1">
<key-stores>
<key-store name="truststore" type="PKCS11">
<key-store-clear-password password="${password}" />
</key-store>
</key-stores>
<ssl-contexts>
<ssl-context name="client-cli-context">
<trust-manager algorithm="SunX509" />
<trust-store key-store-name="truststore" />
<cipher-suite selector="${cipher.suite.filter}" />
<protocol names="${protocol}" />
</ssl-context>
</ssl-contexts>
<ssl-context-rules>
<rule use-ssl-context="client-cli-context" />
</ssl-context-rules>
</authentication-client>
</configuration>
{code}
But there is a exception in log
{code}
13:58:27,652 INFO [com.redhat.eap.qe.cli.CustomCLIExecutor] (main)
java.security.KeyStoreException: JKS not found
at java.security.KeyStore.getInstance(KeyStore.java:851)
at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:59)
at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:52)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.util.AnchorCertificates.<clinit>(AnchorCertificates.java:52)
at
sun.security.provider.certpath.AlgorithmChecker.checkFingerprint(AlgorithmChecker.java:214)
at
sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:164)
at
sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:118)
at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:157)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
at
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:543)
at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:314)
at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:204)
at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98)
at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72)
at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
at
org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
at
org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.security.NoSuchAlgorithmException: JKS KeyStore not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
at java.security.Security.getImpl(Security.java:695)
at java.security.KeyStore.getInstance(KeyStore.java:848)
... 31 more
{code}
When I change SunX509 to PKIX exception does not occure anymore.
Seems exception is thrown by code
https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/sun/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
2808
days inactive
2808
days old
0 comments
1 participants
participants (1)
-
Martin Choma (JIRA)