Is it possible to rely on the local java truststore?

[Gad Berger]

When setting up Dropwizard for Mutual TLS, is it possible to rely on the CA roots that are installed on the server's version of Java, or do we need to explicitly supply a truststore property to the configuration.

Here's my configuration today:

server:

  applicationConnectors:

    - type: https

      port: 8443

      # Key store settings

      keyStorePath: "{keystore-path}"

      keyStorePassword: "{keystore-secret}"

      certAlias: server-tls

      # Explicitly not setting trust store (rely on system)

      # Whether to require authentication by peer certificate.

      needClientAuth: true

      supportedProtocols: [ "TLSv1.3" ]

      allowRenegotiation: true

We have two root certificates installed on the server, the one that the keystore was signed with and another one that we also trust. When I check with keytool, I can see that both trust stores are present on the server. The Java version is Azul Java 11.

keytool -list -cacerts

When we make a client request with a client certificate signed with the same root as the server's keystore root, mutual TLS authentication completes successfully. When we make a client request with a client certificate signed with one of the roots that matches the server's cacerts, but not the server's keystore root, mutual TLS quits with an error that indicates that certificate cannot be verified because it cannot find the root chain.

Is this an error in my understanding? Should Dropwizard not rely on the root certificate chains that are installed on the server?

Thank you,

Gad

[Peter Stackle]

It looks like when Jetty does not have a trust store configured, it does not default to the JVM's trust store, it instead defaults to the configured key store that you are using. I think that matches up with the behavior you are seeing. 

https://github.com/eclipse/jetty.project/blob/jetty-9.4.43.v20210629/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java#L1213-L1225

In general, for mTLS, I'd recommend explicitly configuring a trust store that is limited only to the root certificates that you trust to issue your client certificates. Since other things typically rely on the JVM trust store containing certain roots, it's more likely that you'd end up adding additional certs to the JVM trust store as you add third party integrations over time, at which point, you'd end up expanding the scope of client certs your server trusts when that likely is _not_ what you want.