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
—
