[
https://issues.apache.org/jira/browse/SOLR-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-9040:
---------------------------
Attachment: SOLR-9040.patch
Ok, so the underlying problem with the old patch was that
PoolingHttpClientConnectionManager's default behavior is to use
{{SSLConnectionSocketFactory.getSocketFactory()}} which uses
{{SSLContexts.createDefault()}} under the hood.
{{SSLContexts.createDefault()}} constructs an explicit SSLCOntext that ignores
any system properties.
Instead we want {{SSLConnectionSocketFactory.getSystemSocketFactory()}}, which
does pay attention to some sys properties directly, and usees the standard
{{SSLSocketFactory.getDefault()}} under the hood -- ensuring that the
{{javax.net.ssl.*}} system properties are also respected.
The only problem is that the way {{SSLSocketFactory.getDefault()}} works
involves using {{SSLContext.getDefault()}}, which loads the deafault SSLContext
(and reads the system properties) only once and then treats it as a singleton
-- making it a bit tricky to actually unit test diff sys prop options after the
JVM has already started.
I'll comment more on this in SOLR-9028 where it makes more sense.
in any case, here's a patch that seems to fix {{bin/solr}} (and any {{new
HttpSolrClient(String)}} usage that expects the various SSL sys props to affect
the keystore/truststore).
I've punted on the earlier questions i raised about the
{{SchemaRegistryProvider}} API -- I'll leave it to mark to decide if he thinks
it's worth opening an issue to improve this.
> bin/solr SSL support for client->server communcation (as well as default SSL
> behavior in 'new HttpSolrClient(String)') broken on master
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-9040
> URL: https://issues.apache.org/jira/browse/SOLR-9040
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: SOLR-9040.patch, SOLR-9040.patch
>
>
> Working on SOLR-9028 lead me to realize that {{bin/solr}} actions which
> require communicating with solr over HTTP are broken on master when SSL is
> enabled. My testing suggests that this doesn't affect branch 6x or 6.0.
> (Long) detailed steps to reproduce to follow in first comment
> Further investigation indicates this is a general problem with HTTP based
> SolrClient initialization when standard {{javax.net.ssl.*}} sys properties
> are expected to be used for initializing the underlying HTTP client code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
