Jackrabbit WebDav: Support for TLS client certificates

[Graham Leggett <mi...@sharp.fm>]

Hi all,

I have got to the second line of the example code, and am stuck logging in with a client certificate:

	Repository repository = JcrUtils.getRepository(“https://f.q.d.n/storage/repository");
	Session session = repository.login();

The login() method above fails because no client certificate was negotiated with f.q.d.n (curl works fine) and the server correctly says no (wireshark confirms no).

The underlying tomcat has the following parameters, but they have no effect on jackrabbit/httpclient:

	-Djavax.net.ssl.keyStore=[snip]/cert.p12 -Djavax.net.ssl.keyStorePassword=[snip] -Djavax.net.ssl.keyStoreType=PKCS12 -Djsse.enableSNIExtension=true

A deep dive into the source for jackrabbit shows these two parameters, that appear to signal to HttpClient that the system parameters above should be used, but these too have no effect:

	-Djackrabbit.client.useSystemProperties=true -Dorg.apache.jackrabbit.spi2dav.connection.useSystemProperties=true

Does jackrabbit have a way to tell HttpClient to use system properties, that in turn allows standard java TLS parameters to be respected?

Happy to patch this to fix it, but I need to know where to patch, and if patching is needed.

Regards,
Graham
—

Re: Jackrabbit WebDav: Support for TLS client certificates

[Graham Leggett <mi...@sharp.fm>]

On 09 Jun 2022, at 00:10, Graham Leggett <mi...@sharp.fm> wrote:

> Does jackrabbit have a way to tell HttpClient to use system properties, that in turn allows standard java TLS parameters to be respected?

Picking apart the code, it sees the answer is yes, then no.

A parameter jackrabbit.client.useSystemProperties was added not long ago which triggers the following code:

https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-spi2dav/src/main/java/org/apache/jackrabbit/spi2dav/RepositoryServiceImpl.java#L373

            log.debug("Using system properties for establishing connection!");
            // support Java system proxy? (JCR-3211)
            hcb.useSystemProperties();

Shortly afterwards we run this code that undoes the above:

https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-spi2dav/src/main/java/org/apache/jackrabbit/spi2dav/RepositoryServiceImpl.java#L379

            if (connectionOptions.isAllowSelfSignedCertificates()) {
                log.warn("Nonsecure TLS setting: Accepting self-signed certificates!");
                    sslContext = SSLContextBuilder.create().loadTrustMaterial(new TrustSelfSignedStrategy()).build();
                    hcb.setSSLContext(sslContext);
            } else {
                sslContext = SSLContextBuilder.create().build();
            }

In the above code, it appears we either create a SSLContextBuilder that overrides the default with the self signed strategy, or we create a SSLContextBuilder that just overrides the default, hiding all javax.net.ssl parameters.

Looks like this stopped working recently here:

Little-Net:rackjabbit-trunk minfrin$ svn log -c 1879988
------------------------------------------------------------------------
r1879988 | reschke | 2020-07-17 10:19:38 +0200 (Fri, 17 Jul 2020) | 3 lines

JCR-4536: spi2dav: allow disabling cert and host name checks for TLS connections (also adds test coverage for proxy config)

patch by Konrad Windszus (kwin)
------------------------------------------------------------------------

Will carry on digging - the javadocs for SSLContextBuilder are largely blank, so it isn’t clear what the behaviour should be.

Regards,
Graham
—