[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000139#comment-17000139
]
Kevin Risden edited comment on SOLR-14106 at 12/19/19 3:37 PM:
---------------------------------------------------------------
{quote}My client uses SSL client auth between Solr clients and Solr, and custom
plugins inside Solr also reach out to external services that need SSL client
auth, so there need to be more than one cert in the keystore.. I thought TLS
had built-in handshake to select a certificate based on host or
something.{quote}
In the case above, the client/plugin is trying to reuse the HttpClient that
Solr already created? I think it would be cleaner for the plugin to create and
use a specific HttpClient configured for its use case?
----
In my head, each client should be identified by one clientAuth certificate. I
don't know of any mechanism that will select a client certificate to present
based on the target. So having multiple clientAuth certificates to choose from
definitely seems wrong on the client side.
On the server side, the server needs to present a certificate for the hostname
involved. This is SNI where the server side will choose which certificate to
serve up to the client. There can be multiple certificates in a keystore on the
server side.
----
So I think the error message is actually correct. I think the custom plugin
needs to have a separate HttpClient instance that is configured with a
different keystore. This would avoid having to put multiple clientAuth
certificates in the one keystore and reusing the Solr HttpClient.
PS - I think prior to the recent Jetty changes if I read the issues you linked
correctly, that Jetty would just choose one of the clientAuth certificates if
there were multiple in the client keystore. At least now Jetty httpclient is
saying hey this isn't what we expected you to be trying to do.
was (Author: risdenk):
{quote}My client uses SSL client auth between Solr clients and Solr, and custom
plugins inside Solr also reach out to external services that need SSL client
auth, so there need to be more than one cert in the keystore.. I thought TLS
had built-in handshake to select a certificate based on host or
something.{quote}
In the case above, the client is trying to reuse the HttpClient that Solr
already created? I think it would be cleaner for the plugin to create and use a
specific HttpClient configured for its use case?
----
In my head, each client should be identified by one clientAuth certificate. I
don't know of any mechanism that will select a client certificate to present
based on the target. So having multiple clientAuth certificates to choose from
definitely seems wrong on the client side.
On the server side, the server needs to present a certificate for the hostname
involved. This is SNI where the server side will choose which certificate to
serve up to the client. There can be multiple certificates in a keystore on the
server side.
----
So I think the error message is actually correct. I think the custom plugin
needs to have a separate HttpClient instance that is configured with a
different keystore. This would avoid having to put multiple clientAuth
certificates in the one keystore and reusing the Solr HttpClient.
PS - I think prior to the recent Jetty changes if I read the issues you linked
correctly, that Jetty would just choose one of the clientAuth certificates if
there were multiple in the client keystore. At least now Jetty httpclient is
saying hey this isn't what we expected you to be trying to do.
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> -----------------------------------------------------------
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
> Affects Versions: 8.2, 8.3, 8.4, 8.3.1
> Reporter: Jan Høydahl
> Assignee: Kevin Risden
> Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
