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

[kga.official]

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

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

[meuel]

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.