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. On Wednesday, October 6, 2021 at 10:40:49 AM UTC-7 [email protected] wrote: > 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 > -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dropwizard-user/4c7dccf7-d4c6-446b-acdf-4bfec2d577f9n%40googlegroups.com.
