2 Replies Latest reply on Feb 18, 2020 11:49 AM by meuel

    Elytron Remoting from non-WildFly context ignores ssl-context-rules

    kga.official
    kga.official Jan 6, 2020 5:46 AM

      Hi,

       

      I am trying to remotely connect to a WildFly 18.0.1 server using a remote (non-WildFly) Elytron Remoting connection. This will be for a Remote EJB call.

       

      I have disabled server side authentication for remoting. I plan to rely on Client Certificate SSL for the authentication.

       

      Client Side Configuration:

      <authentication-client xmlns="urn:elytron:client:1.2">

              <key-stores>

                  <key-store name="client-keystore" type="JKS" alias="clientalias">

                      <file name="/home/myuser/libs/remoting.client.keystore"/>

                      <key-store-clear-password password="abcdef"/>

                  </key-store>

                  <key-store name="client-truststore" type="JKS">

                      <file name="/home/myuser/libs/remoting.client.truststore"/>

      <key-store-clear-password password="abcdef"/>

                  </key-store>

              </key-stores>

              <ssl-contexts>

                  <ssl-context name="client-ssl-context">

                      <trust-store key-store-name="client-truststore"/>

                      <key-store-ssl-certificate key-store-name="client-keystore" alias="clientalias">

                          <key-store-clear-password password="abcdef"/>

                      </key-store-ssl-certificate>

                  </ssl-context>

       

              </ssl-contexts>

              <ssl-context-rules>

                  <rule use-ssl-context="client-ssl-context">

      <match-host name="MyHostName"/>

      <match-host name="10.10.10.10"/>

      </rule>

      <rule use-ssl-context="client-ssl-context">

      </rule>

      <rule use-ssl-context="client-ssl-context">

      <match-no-user />

      </rule>

              </ssl-context-rules>

      </authentication-client>

       

      Server Side (relevant snippet):

                  <tls>

                      <key-stores>

                          <key-store name="remoting-server-key-store">

                              <credential-reference clear-text="mypassword"/>

                              <implementation type="JKS"/>

                              <file path="truecontrol.keystore" relative-to="jboss.server.config.dir"/>

                          </key-store>

                          <key-store name="remoting-server-trust-store">

                              <credential-reference clear-text="mypassword"/>

                              <implementation type="JKS"/>

                              <file path="truecontrol.truststore" relative-to="jboss.server.config.dir"/>

                          </key-store>

                      </key-stores>

                      <key-managers>

                          <key-manager name="remoting-key-manager" key-store="remoting-server-key-store">

                              <credential-reference clear-text="mypassword"/>

                          </key-manager>

                      </key-managers>

                      <trust-managers>

                          <trust-manager name="remoting-trust-manager" key-store="remoting-server-trust-store"/>

                      </trust-managers>

                      <server-ssl-contexts>

                          <server-ssl-context name="remoting-ssl-context" want-client-auth="true" need-client-auth="true" key-manager="remoting-key-manager" trust-manager="remoting-trust-manager"/>

                      </server-ssl-contexts>

                  </tls>

       

      Launching the Java Code with:

      -Dwildfly.config.url=/home/myuser/libs/wildfly-config.xml

       

      Error I get (after enabling SSL Debug in Java):

      <snip>

      Inaccessible trust store: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.222.b10-1.el7_7.x86_64/jre/lib/security/jssecacerts

      trustStore is: /etc/pki/java/cacerts

      trustStore type is: jks

      trustStore provider is:

      the last modified time is: Wed Feb 06 05:56:07 PST 2019

      Reload the trust store

      Reload trust certs

      Reloaded 133 trust certs

      adding as trusted cert:

        Subject: CN=Hongkong Post Root CA 1, O=Hongkong Post, C=HK

        Issuer:  CN=Hongkong Post Root CA 1, O=Hongkong Post, C=HK

        Algorithm: RSA; Serial number: 0x3e8

        Valid from Wed May 14 22:13:14 PDT 2003 until Sun May 14 21:52:29 PDT 2023

      <snip>

      XNIO-1 I/O-1, fatal error: 46: General SSLEngine problem

      sun.security.validator.ValidatorException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.

       

      Detailed Exception:

              Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem

                      at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)

                      at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1709)

                      at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:318)

                      at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)

                      at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)

                      at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)

                      at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)

                      at sun.security.ssl.Handshaker$1.run(Handshaker.java:970)

                      at sun.security.ssl.Handshaker$1.run(Handshaker.java:967)

                      at java.security.AccessController.doPrivileged(Native Method)

                      at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1459)

                      at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:547)

                      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: sun.security.validator.ValidatorException: PKIX path building failed: java.security.cert.CertPathBuilderException: U

      nable to find certificate chain.

                      at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)

                      at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)

                      at sun.security.validator.Validator.validate(Validator.java:262)

                      at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)

                      at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:289)

                      at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:144)

                      at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1626)

                      ... 18 more

              Caused by: java.security.cert.CertPathBuilderException: Unable to find certificate chain.

                      at org.bouncycastle.jcajce.provider.PKIXCertPathBuilderSpi.engineBuild(Unknown Source)

                      at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)

                      at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)

                      ... 24 more

       

      Essentially, the client side library isn't using the configured truststore in the wildfly-config.xml

       

      I downloaded the wildfly-client sources.jar and did a bit of debugging and found that org.jboss.remotingjmx.RemotingConnector doesn't even get initialized. Other Subsystems in the XML are initialized.

       

      Any help?

       

      Using client version wildfly-client-all-18.0.1.Final.jar (which is a "fat" JAR, does that make a difference?)

        • 1. Re: Elytron Remoting from non-WildFly context ignores ssl-context-rules
          kga.official
          kga.official Jan 7, 2020 10:50 AM (in response to kga.official)

          public final class AuthenticationContext implements Contextual<AuthenticationContext> {

           

            private static final ContextManager<AuthenticationContext> CONTEXT_MANAGER = new ContextManager<AuthenticationContext>(AuthenticationContext.class);

           

            private static final Supplier<AuthenticationContext> SUPPLIER = doPrivileged((PrivilegedAction<Supplier<AuthenticationContext>>) CONTEXT_MANAGER::getPrivilegedSupplier);

           

            static {

            Version.getVersion();

            CONTEXT_MANAGER.setGlobalDefaultSupplier(() -> DefaultAuthenticationContextProvider.DEFAULT);

            }

           

          The above code is the ONLY reference to the org/wildfly/security/auth/client/ElytronXmlParser.java in the wildfly-client. Given that the static initalization block will be run AFTER the two static variables are initialized, the SUPPLIER might NOT get the "DefaultAuthenticationContextProvider.DEFAULT" one as that is set later.

           

          Is there another explanation why wildfly-client completely ignores the SSL configuration done via wildfly-config.xml?

            • Actions
          • 2. Re: Elytron Remoting from non-WildFly context ignores ssl-context-rules
            meuel
            meuel Feb 18, 2020 11:49 AM (in response to kga.official)

            Your seem to be messed up a little. One rule contaqins two elements (which is not allowed btw) and one has not <match-*> element. This may be the reason that no rule matches and the configured ssl-context isn't used. Instead a default ss-context (the one with the default trust manager without your custom certificate) will be used.

              • Actions