You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Kevin Risden (Jira)" <ji...@apache.org> on 2019/12/19 15:38:00 UTC
[jira] [Comment Edited] (SOLR-14106) SSL with
SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org