Uploaded image for project: 'WildFly Elytron'
  1. WildFly Elytron
  2. ELY-1648

FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5.5.Final
    • Fix Version/s: None
    • Component/s: SSL
    • Labels:
      None
    • Steps to Reproduce:
      Hide
      • Run server and jboss-cli client with FIPS java
      /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
      

      Exception thrown from CLI (not in server.log) while trying to reconnect

      Show
      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 /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 Exception thrown from CLI (not in server.log) while trying to reconnect

      Description

      With SunX509 truststore algorithm I can succesfully connect with CLI.

      <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>
      

      But there is a exception in log

      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
      

      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/security/util/AnchorCertificates.java#L59
      AnchorCertificates hardcodes JKS keystore creation. Apparently using PKIX it is avoided.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                mchoma Martin Choma
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: