Hi I don't know what I am missing:
Setup a bonsai.oi account and can't connect using this library at all
First tried:
require 'vendor/autoload.php';
$params = array();
$params['hosts'] = array (
'https://user:[email protected]' // SSL + HTTP Basic Auth
);
$client = new ElasticsearchClient($params);
$getParams = array();
$getParams['index'] = 'my_index';
$getParams['type'] = 'my_type';
$getParams['id'] = 'my_id';
$retDoc = $client->get($getParams);
Get error:
Fatal error: Uncaught exception 'ElasticsearchCommon\Exceptions\TransportException' with message 'error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol' in /Users/raynoppe/Dropbox/development/itsonamap/www/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Connections/AbstractConnection.php:324 Stack trace: #0 /Users/raynoppe/Dropbox/development/itsonamap/www/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Connections/GuzzleConnection.php(313): ElasticsearchConnectionsAbstractConnection->throwCurlException(35, 'error:140770FC:...') #1 /Users/raynoppe/Dropbox/development/itsonamap/www/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Connections/GuzzleConnection.php(200): ElasticsearchConnections\GuzzleConnection->processCurlError(Object(Guzzle\Http\ExceptionCurlException)) #2 /Users/raynoppe/Dropbox/development/itsonamap/www/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Connections/GuzzleConnection.php(104): ElasticsearchConnections\GuzzleConnection->sendRequest(Object(Guzzle\Http\Mess in /Users/raynoppe/Dropbox/development/itsonamap/www/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Connections/AbstractConnection.php on line 324
Also tried:
require 'vendor/autoload.php';
$params = array();
$params['hosts'] = array (
'https://user:[email protected]' // SSL + HTTP Basic Auth
);
$params['connectionPoolClass'] = '\ElasticsearchConnectionsCurlMultiConnection';
$client = new ElasticsearchClient($params);
$getParams = array();
$getParams['index'] = 'my_index';
$getParams['type'] = 'my_type';
$getParams['id'] = 'my_id';
$retDoc = $client->get($getParams);
Get the error:
Catchable fatal error: Argument 3 passed to ElasticsearchConnectionsCurlMultiConnection::__construct() must implement interface Psr\Log\LoggerInterface, instance of ElasticsearchConnectionsConnectionFactory given, called in /Users/raynoppe/Dropbox/development/itsonamap/www/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Common/DICBuilder.php on line 239 and defined in /Users/raynoppe/Dropbox/development/itsonamap/www/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Connections/CurlMultiConnection.php on line 63
If I use the elastica library it works fine. Also tried connecting via command line: also working fine.
Help and advice appreciated.
Ray
Can you try a non-SSL connection first, to verify that basic HTTP is working through the client? SSL always makes things trickier. Try this (I also added a catch so we can get a prettier error message):
require 'vendor/autoload.php';
$params = array();
$params['hosts'] = array (
'http://user:[email protected]' // Note: I changed this to just http
);
$client = new Elasticsearch\Client($params);
$getParams = array();
$getParams['index'] = 'my_index';
$getParams['type'] = 'my_type';
$getParams['id'] = 'my_id';
try {
$retDoc = $client->get($getParams);
} catch ($e \Exception) {
print_r($e->getMessage());
print_r($client->transport->getLastConnection()->getLastRequestInfo());
}
About your second error...it looks like I have an error in the documentation about changing the connection class, it should say connectionClass, not connectionPoolClass. Sorry for the confusion!
If you want to try CurlMultiConnection, you can do this:
$params['connectionClass'] = '\Elasticsearch\Connections\CurlMultiConnection';
I will fix the docs in just a sec.
WOW thank you for that.
It is indeed a SSL problem. If I change to http both versions work just fine. I then thought to try it with Facetflow and one of our own production servers, just incase it was a problem on bonsai.io. Same error with both guzzle and CurlMultiConnection across all three:
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocolArray
(
[request] => Array
(
[uri] => https://mapped-fashion-xxx.eu-west-1.bonsai.io:9200/my_index/my_type/my_id?
[body] =>
[options] => Array
(
[auth] => Array
(
[0] => xxx
[1] => xxx
[2] => Basic
)
)
[method] => GET
)
)
In also referenced how we interact with our couchdb servers via php (ssl) and noted we use version 5 of guzzle where as you use version 3. Maybe a problem with guzzle?
Thank you for your help.
Hm. So the SSL23_GET_SERVER_HELLO:unknown protocol error basically means the SSL server received a request in an unknown SSL protocol. So this could be a mismatch in the SSL modes (e.g. your PHP box only knows TLS 1.0 but the server wants TLS 1.2). It could also mean the client is sending plaintext, not encrypted SSL. It could also be sending the request to the wrong port.
Can you run openssl s_client -debug -connect mapped-fashion-xxxxxxxxx.eu-west-1.bonsai.io:443. That should tell you what kind of SSL encryption the server is expecting, before it closes the connection with the error
I also just tagged a v1.3.4 which fixes an inline auth bug. I don't think it is affecting you, but wouldn't hurt to upgrade just in case
In also referenced how we interact with our couchdb servers via php (ssl) and noted we use version 5 of guzzle where as you use version 3. Maybe a problem with guzzle?
Maybe, but I doubt it. The core of both is libcurl, so that shouldn't really affect things. If you're curious, you could upgrade to ES-PHP v2.0.0-beta1, which uses RingPHP (the core that Guzzle5 uses for HTTP).
Closing due to inactivity, please feel free to re-open if you have any more info.
Still happens for me. It happens on Heroku with PHP7.
Specifically I get this error, when I try to index my stuff: Elasticsearch\Common\Exceptions\TransportException with message 'cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol'
I can connect to the instance just fine without SSL. I also use bonsai.io with HTTP basic auth.
Any ideas @polyfractal?
Heya @onbjerg, I'm unfortunately out traveling this week for a work trip (training). I'll try to poke at this when I get a chance, but it may be radio silence until friday/early next week, depending on how busy my days are.
If you haven't figured it out before I get to it, I'll open up a Heroku account and see if I can debug it myself.
What OS are you using? Curl version? Could you try that openssl command that I suggested to raynoppe?
Hey @polyfractal. No worries, it can wait.
Heroku is using Ubuntu 14.04 (they call it the cedar-14 stack).
Output of curl --version from the server:
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
Output from openssl s_client -debug -connect mapped-fashion-xxxxxxxxx.eu-west-1.bonsai.io:443: https://gist.github.com/onbjerg/5f08e2b2bffec3e1f815
Cool, thanks. Are you connecting from heroku to localhost, or from your machine to heroku?
It seems the server wants TLSv1/SSLv3, can you try doing something like this:
$client = Elasticsearch\ClientBuilder::create()->build();
$params = [
'index' => 'test',
'type' => 'test',
'body' => [
'query' => [
'match_all' => []
]
],
'client' => [
'curl' => [
CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1
]
]
];
$client->search($params);
Shot in the dark, SSL isn't my forte. :)
(Reopening so I don't forget about this ticket too)
Edit: Note, if this turns out to be the problem... we should keep digging, because I believe TLSv1/SSLv3 is not safe to use :)
It's not safe at all. I'm connecting to Bonsai (which is using TLSv1) from a Heroku instance. I'll look at your suggestion a bit later.
I've just experienced the same errors against Bonsai and Elastic Cloud (former Found.no). The error reported was cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol which had me troubleshoot cURL config/version etc.
But it turned out that what @polyfractal wrote above....
_It could also be sending the request to the wrong port._
...was the issue, so changing from...
https://user:[email protected]
...to...
https://user:[email protected]:443
...solved the problem because without it the client was trying to talk to 9200 (despite the https://).
solved the problem because without it the client was trying to talk to 9200 (despite the https://).
Yeah, this has been a problem at times. It's tricky, since ES always uses port 9200 by default since it doesn't offer SSL out of the box. And even if you use Shield to provide SSL, it still uses port 9200.
It's only when someone sets up a reverse proxy that is SSL-enabled does the port change, usually to 443 but sometimes different. Unclear what the default should be set to, since it depends on what kind of architecture you have up and running. So we just stick with 9200.
Perhaps a big callout in the docs to help make it more clear?
Wouldn't defaulting to 443 in the case of a https:// url make more sense or would that cause 馃槺 and 馃挜 in terms of backwards compatibility?
It would likely cause 馃槺 and 馃挜 bwc problems :)
Honestly there isn't a good default here: half of people using SSL use Shield and the default 9200 port, the other half have a proxy like nginx. So we should stick with 9200 as the default, since it defaults to that for non-SSL even though the plain URL would suggest it should be port 80 instead.
As far as I know, https default port is 443 at https://tools.ietf.org/html/rfc2818#section-2.3
So if I see https://.... I expect to be connecting to port 443, unless I set the port number in the URL.
Just my 2 cents.
Closing, no plans to change the default port from 9200.
Most helpful comment
I've just experienced the same errors against Bonsai and Elastic Cloud (former Found.no). The error reported was
cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocolwhich had me troubleshoot cURL config/version etc.But it turned out that what @polyfractal wrote above....
...was the issue, so changing from...
https://user:[email protected]...to...
https://user:[email protected]:443...solved the problem because without it the client was trying to talk to 9200 (despite the
https://).