Fixed reCapture error

ibaker

Well-known member
Affected version
v2 beta 4
Just did a clean install of v2 on a spare domain for testing leaving everything basic and keep on getting a reCapture error:
Server error log
  • GuzzleHttp\Exception\RequestException: ReCAPTCHA connection error: cURL error 60: See http://curl.haxx.se/libcurl/c/libcurl-errors.html
  • src/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:51
  • Generated by: Unknown account
  • Sep 29, 2017 at 2:16 PM
Stack trace
#0 src/vendor/guzzlehttp/guzzle/src/RequestFsm.php(104): GuzzleHttp\Exception\RequestException::wrapException(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Ring\Exception\RingException)) #1 src/vendor/guzzlehttp/guzzle/src/RequestFsm.php(132): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction)) #2 src/vendor/react/promise/src/FulfilledPromise.php(25): GuzzleHttp\RequestFsm->GuzzleHttp\{closure}(Array) #3 src/vendor/react/promise/src/Promise.php(119): React\Promise\FulfilledPromise->then(Object(Closure), NULL) #4 src/vendor/react/promise/src/Promise.php(166): React\Promise\Promise->React\Promise\{closure}(Object(React\Promise\FulfilledPromise)) #5 src/vendor/react/promise/src/Promise.php(133): React\Promise\Promise->settle(Object(React\Promise\FulfilledPromise)) #6 src/vendor/react/promise/src/Promise.php(201): React\Promise\Promise->resolve(Array) #7 [internal function]: React\Promise\Promise->React\Promise\{closure}(Array) #8 src/vendor/react/promise/src/Deferred.php(35): call_user_func(Object(Closure), Array) #9 src/vendor/guzzlehttp/ringphp/src/Client/CurlMultiHandler.php(247): React\Promise\Deferred->resolve(Array) #10 src/vendor/guzzlehttp/ringphp/src/Client/CurlMultiHandler.php(136): GuzzleHttp\Ring\Client\CurlMultiHandler->processMessages() #11 src/vendor/guzzlehttp/ringphp/src/Future/BaseFutureTrait.php(118): GuzzleHttp\Ring\Client\CurlMultiHandler->execute() #12 src/vendor/guzzlehttp/ringphp/src/Future/BaseFutureTrait.php(55): GuzzleHttp\Ring\Future\FutureArray->invokeWait() #13 src/vendor/guzzlehttp/ringphp/src/Future/BaseFutureTrait.php(118): GuzzleHttp\Ring\Future\FutureArray->wait() #14 src/vendor/guzzlehttp/ringphp/src/Future/BaseFutureTrait.php(55): GuzzleHttp\Message\FutureResponse->invokeWait() #15 src/vendor/guzzlehttp/guzzle/src/Client.php(176): GuzzleHttp\Message\FutureResponse->wait() #16 src/vendor/guzzlehttp/guzzle/src/Client.php(150): GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request)) #17 src/XF/Captcha/ReCaptcha.php(83): GuzzleHttp\Client->post('https://www.goo...', Array) #18 src/XF/Mvc/Controller.php(771): XF\Captcha\ReCaptcha->isValid() #19 src/XF/Pub/Controller/Register.php(344): XF\Mvc\Controller->captchaIsValid() #20 src/XF/Mvc/Dispatcher.php(249): XF\Pub\Controller\Register->actionRegister(Object(XF\Mvc\ParameterBag)) #21 src/XF/Mvc/Dispatcher.php(89): XF\Mvc\Dispatcher->dispatchClass('XF:Register', 'register', 'json', Object(XF\Mvc\ParameterBag), '', Object(XF\Pub\Controller\Register), NULL) #22 src/XF/Mvc/Dispatcher.php(41): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch)) #23 src/XF/App.php(1787): XF\Mvc\Dispatcher->run() #24 src/XF.php(326): XF\App->run() #25 index.php(13): XF::runApp('XF\\Pub\\App') #26 {main}
-------------
Previous GuzzleHttp\Ring\Exception\RingException: cURL error 60: See http://curl.haxx.se/libcurl/c/libcurl-errors.html - src/vendor/guzzlehttp/ringphp/src/Client/CurlFactory.php:127 #0 src/vendor/guzzlehttp/ringphp/src/Client/CurlFactory.php(91): GuzzleHttp\Ring\Client\CurlFactory::createErrorResponse(Object(GuzzleHttp\Ring\Client\CurlMultiHandler), Array, Array) #1 src/vendor/guzzlehttp/ringphp/src/Client/CurlMultiHandler.php(244): GuzzleHttp\Ring\Client\CurlFactory::createResponse(Object(GuzzleHttp\Ring\Client\CurlMultiHandler), Array, Array, Array, Resource id #111) #2 src/vendor/guzzlehttp/ringphp/src/Client/CurlMultiHandler.php(136): GuzzleHttp\Ring\Client\CurlMultiHandler->processMessages() #3 src/vendor/guzzlehttp/ringphp/src/Future/BaseFutureTrait.php(118): GuzzleHttp\Ring\Client\CurlMultiHandler->execute() #4 src/vendor/guzzlehttp/ringphp/src/Future/BaseFutureTrait.php(55): GuzzleHttp\Ring\Future\FutureArray->invokeWait() #5 src/vendor/guzzlehttp/ringphp/src/Future/BaseFutureTrait.php(118): GuzzleHttp\Ring\Future\FutureArray->wait() #6 src/vendor/guzzlehttp/ringphp/src/Future/BaseFutureTrait.php(55): GuzzleHttp\Message\FutureResponse->invokeWait() #7 src/vendor/guzzlehttp/guzzle/src/Client.php(176): GuzzleHttp\Message\FutureResponse->wait() #8 src/vendor/guzzlehttp/guzzle/src/Client.php(150): GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request)) #9 src/XF/Captcha/ReCaptcha.php(83): GuzzleHttp\Client->post('https://www.goo...', Array) #10 src/XF/Mvc/Controller.php(771): XF\Captcha\ReCaptcha->isValid() #11 src/XF/Pub/Controller/Register.php(344): XF\Mvc\Controller->captchaIsValid() #12 src/XF/Mvc/Dispatcher.php(249): XF\Pub\Controller\Register->actionRegister(Object(XF\Mvc\ParameterBag)) #13 src/XF/Mvc/Dispatcher.php(89): XF\Mvc\Dispatcher->dispatchClass('XF:Register', 'register', 'json', Object(XF\Mvc\ParameterBag), '', Object(XF\Pub\Controller\Register), NULL) #14 src/XF/Mvc/Dispatcher.php(41): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch)) #15 src/XF/App.php(1787): XF\Mvc\Dispatcher->run() #16 src/XF.php(326): XF\App->run() #17 index.php(13): XF::runApp('XF\\Pub\\App') #18 {main} Request state
array(4) { ["url"] => string(18) "/register/register" ["referrer"] => string(36) "http://www.xyz.com.au/register/" ["_GET"] => array(0) { } ["_POST"] => array(15) { ["username"] => string(0) "" ["146e6b59f9d10f5ede159ec21ff72a0fb32da352"] => string(7) "xxx" ["370e2347657873385931416de90624cadc6234e2"] => string(25) "xxx@outlook.com.au" ["9346ebdfbad5a836cdd08c125114b6406669b60d"] => string(8) "********" ["dob_month"] => string(1) "xx" ["dob_day"] => string(2) "xx" ["dob_year"] => string(4) "xxxx" ["location"] => string(8) "Goulburn" ["g-recaptcha-response"] => string(505) "03AJzQf7P6umdNHMX_8_RdRDZEc5d7biJcCmbM6uzMM1GKeIP7_UAV9m3LdLWTVGoyJ1D4HWfePT1rP9eM94V7ESSyapzucF6uZKCCyZeBqY8RxTDHHYuaYkex6tT264awEKzaYlN484udAtnHW6O1h5OTq1zlx3N2w1kOPy7NfUaeVtuK0r8ZsRpE3_03HK9YUgXIVG0K8GWUY0QfYjq4GtobdCnvzpNyyTgzH8A8fwWSYG_4ulN4tmE_CFt10Vt23lElAxL0SUmwGoboMW95zjM3-pA5kZ-IyBmaVtYnLP9OJTLvWa4aeTZCNyR8nM2HAWbn8GaCgXHi0OZbSZGZVijGNgT8DvFFtU0AMPez1IHXV5aKOidLc6ktamFwpecHeMRVDLEXTc336UvL4k7FlRFGXJMAUNR79LsB8q-frPK6vYadbZasnTTaGuTCmWwJ84f3G3Z0gPtb-9GNShbrDIw4eLEMY6YHfODUlovpg5Qd0008euFoCYk" ["reg_key"] => string(16) "poBQZLq3hw4lDuoI" ["fcef3adbf1fd9331ab91f9d8a747a494c7b071c9"] => string(16) "Australia/Sydney" ["_xfToken"] => string(8) "********" ["_xfRequestUri"] => string(10) "/register/" ["_xfWithData"] => string(1) "1" ["_xfResponseType"] => string(4) "json" } }
 
IIRC this could be an outdated cURL or SSL library used within cURL, however, would you mind checking phpinfo and letting us know the values from the curl section? You can access phpinfo from admin.php?tools/phpinfo. e.g.

1508179239812.webp
 
Nothing reproducible at this stage though I believe it could be related specifically to the SSL Version which is listed as OpenSSL/1.0.1e.

It's worth noting that this version is vulnerable to the Heartbleed exploit (http://heartbleed.com/) unless it has been patched in some other way, which really should have been done years ago.

I'd start there in the first instance. You want to be running at least OpenSSL 1.0.1g though there have been many releases since.
 
What are you talking about? Are you serious? Don't blame if you don't know anything. The problem is ignorance from the user.

http://news.cpanel.com/heartbleed-vulnerability-information/
OpenSSL is provided by the core operating system. I installed an SSL certificate on your site but it is your responsibility to keep your OS upgraded, which is something you haven't done.
 
Nothing reproducible at this stage though I believe it could be related specifically to the SSL Version which is listed as OpenSSL/1.0.1e.

It's worth noting that this version is vulnerable to the Heartbleed exploit (http://heartbleed.com/) unless it has been patched in some other way, which really should have been done years ago.

I'd start there in the first instance. You want to be running at least OpenSSL 1.0.1g though there have been many releases since.
ibaker - I would speak with your web host and find out why they are still using a SSL version that's almost 6 years old.

It's worth noting that RHEL distributions of 1.0.1e are not susceptible to heart bleed. It was in fact the most currently supported version until CentOS 7.3. 1.0.2k is now the latest supported version and great for ALPN support.

Red Hat back ports fixes into their distribution of packages rather than rebasing every time we turn around. Better for stability that way. My personal server had something other than 1.0.1e-fips installed and horribly failed the update to the lastest CentOS. I think it was the result of some bad experiements. None of my other servers had the same issue lol.
 
Guys, I am nearly 60 years old and all this tech stuff is way pass me now hence why I pay people to do things now compared to the days when I was using punch cards. A friend who was an IT Manager for a local council when turning 40 said he can't keep up with tech things anymore so left the industry and became a kindergarten teacher.

The fact is I would have assumed that when paying someone to do something they would inform me of anything that I need to know however I can also understand that people try to do the right thing and do the job they are paid to do.

So it seems the best solution is to now pay someone to update my server to all the latest releases even though it still ticks the requirements as outlined for v2 there are some things that are not clearly defined for v2.

Thanks
 
Guys, I am nearly 60 years old and all this tech stuff is way pass me now hence why I pay people to do things now compared to the days when I was using punch cards. A friend who was an IT Manager for a local council when turning 40 said he can't keep up with tech things anymore so left the industry and became a kindergarten teacher.

The fact is I would have assumed that when paying someone to do something they would inform me of anything that I need to know however I can also understand that people try to do the right thing and do the job they are paid to do.

So it seems the best solution is to now pay someone to update my server to all the latest releases even though it still ticks the requirements as outlined for v2 there are some things that are not clearly defined for v2.

Thanks

2.0 is still in beta so it's not as if it should be on a live site at the moment anyway. You have encountered an issue no one has. The solution might be a simple version requirement for underlying server software. But if that is the actual case has yet to be seen. A good bit of customers have no real control over the software on the server. They shop for what they need and things like libcurl and openssl version aren't exactly advertised. It's assumed a modern server is going to be up to date on these things. I am sure if a specific need is found it will be published. If they find the exact cause they might even be able to include code to work around it in the core release of Xenforo.

If you can't manage certain things yourself then it is true you will end up paying someone to assist you. But this early in 2.0 I would say to give it a little time as well. In the mean time see about getting your host to update or find a different host.
 
The fact is I would have assumed that when paying someone to do something they would inform me of anything that I need to know however I can also understand that people try to do the right thing and do the job they are paid to do.
You asked to set HTTPS on your forum, nothing else. Checking if your server is updated and apply patches is something far different from you have asked for.

You may have 60 years but I'm still waiting for you to apologize. For cases like yours is why there managed web hosting exists. If you just buy an unmanaged web server you are responsible for keeping it updated.
 
This does appear to be a OpenSSL-related issue, which cURL is likely using for SSL handling. It's a specific quirk of how Google signs its certificates. There's a rough explanation of the cause here: https://github.com/libressl-portable/portable/issues/80 Ultimately, it has to do with Google's certs being signed by a known root certificate (GeoTrust) but then also signed by an old, now deprecated on as well (Equifax). If the SSL verification only ensures it trusts the last one, it won't because that's not a commonly trusted certificate now. The library handling SSL verification needs to look back up the chain to see if it trusts any intermediate certificates.

One workaround would be to add Equifax's certificate into the trusted list (https://www.geotrust.com/resources/...ates/Equifax_Secure_Certificate_Authority.pem) though I'm very reluctant to do that. There's a reason browsers don't include it any longer. (And that's where the certificate bundle we include comes from.)

Equally, the only other workaround is to disable all SSL certificate verification which mostly defeats the point of SSL. (That can be done by adding $config['http']['sslVerify'] = false; to src/config.php.)

If you can reproduce this, can you confirm what shows in PHP info under cURL's "SSL version" value?
 
Thanks Mike...you are always a star (just wish I knew what you said above though). Anyway I have commissioned a new dedicated server with all the latest versions (works out cheaper than I am paying now with faster processor). Just need someone who knows what they are doing to set the whole server up and ready i.e. Percona, Elasticsearch, SSL cert, hardening, ImageMagick, cache, FFMPEG etc...anyone want a job?
 
I've compromised. We now have two certificate bundles. We detect if cURL is using OpenSSL < 1.0.2 and use the bundle that includes the needed Equifax certificate. For any other cURL install (such as using a newer OpenSSL or NSS), we use the standard CA bundle.
 
Top Bottom