On 10/11/2013 8:17 AM, Christopher Gross wrote: > I have 3 SolrCloud nodes (call them idx1, idx2, idx3), and the boxes have > SSL & certs configured on them to protect the Solr Indexes. > > Right now, I can do queries on idx1 and it works fine. > If I try to query on idx3, I get: > org.apache.solr.common.SolrException: > org.apache.sorl.client.solrj.SolrServerException:IOException occurred when > talking to server at http://idx1:8443/solr/test1 > (and then a long stack trace -- can't copy it, on a test network) > > Is there a spot in a Solr configuration that I can set this up to use HTTPS?
>From what I can tell, not yet. https://issues.apache.org/jira/browse/SOLR-3854 https://issues.apache.org/jira/browse/SOLR-4407 https://issues.apache.org/jira/browse/SOLR-4470 I'm wondering why you want to do this, though. It adds extra CPU overhead. Perhaps not a lot, but it's not free. As for protecting Solr against eavesdropping, is it in a location where that's possible? The bottom line is this: People that you cannot trust should not have direct access to Solr. It should be firewalled so only trusted personnel and applications can talk to it. Anyone who has direct access to Solr can change your index, delete your index, and send denial of service queries. If you take steps to block access to the update handler(s) and the admin UI, denial of service queries are still possible. Blocking access to the update handlers and admin UI is not something Solr itself can do - that's a job for the servlet container. Related general issue: The /browse handler included in the example (which utilizes code written in velocity) requires that the user have direct access to Solr. This makes its very design insecure. That handler is intended as a demonstration of Solr's capabilities and how to use them, it's not for production. Thanks, Shawn
