We have a PHP web application using Algolia PHP Client version 1.17 on our server, in the backend. Algolia is soon deprecating TLS 1.0 and 1.1 entirely.
How do I know which TLS version the PHP backend is using to contact Algolia? Is this strictly a web server configuration issue or is an SDK upgrade required?
The Algolia PHP API Client v1 uses a cURL client for network requests, which picks up the default system SSL version and appropriately leverages the CURLOPT_SSL_VERIFYHOST and CURLOPT_SSL_VERIFYPEER options to enforce the security of the connection.
As long as you’re enforcing TLS 1.2 in your environment, you should be fine.
Related
I have got old PHP 5.3 app on old Debian 6. It uses services via SOAP / CURL / file_get_content (POST/GET) and TLS 1.2 will be required soon to establish a connection.
I have successfully recompiled OpenSSL, CURL, PHP and phpinfo say it uses OpenSSL 1.0.2n so we are good here.
Now I want to be sure PHP Soap and file_get_contents uses TLS 1.2 (not old one) so when the TLS 1.2 day will come - all services will be working fine.
I've tested CURL via https://tlstest.paypal.com and it passes.
How can I test SOAP (SoapClient) and stream_context_create+file_get_content to be sure it uses TLS 1.2?
In PHP 5.6 I can force soap to use TLS1.2 with STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT but it's not available in older PHP version.
Thanks for any suggestions.
Or do you know some TLS 1.2 only services so I could test my server against it?
I'm getting the following error from google:
Google has detected that your site is using an obsolete version of TLS (TLSv1).
My hosting providers say that it's not possible to update the version of TLS on the server as the server is running PHP 5.2.17 (due to it currently running an antique application).
The Apache version is 2.2.34.
Is it possible to update TLS whilst keeping this version of PHP?
What are the consequences of running TLS v1?
I recently disabled TLS 1.0 & TLS 1.1 on a web server, but it seems to have caused some issues with some of the PHP sites I'm running.
The error in question is: "[Microsoft][ODBC Driver 11 for SQL Server]Encryption not supported on the client." but I have other sites running on TLS 1.2 on the same server, I even have other PHP-based sites still able to connect to the database despite being earlier versions of PHP (5.3.28, which I think might've even been before TLS 1.2 support was added.. so not sure how they're still functional considering the server is now restricted to TLS 1.2 only).
Anyway, I've been troubleshooting this quite a while now, and would greatly appreciate any new ideas to try.
Additional Info:
Server: Windows Server 2012 R2 Standard (IIS 8)
PHP Version: 7.0.17
curl version: 7.47.1
SSL version: OpenSSL/1.0.2h
OPENSSL_VERSION_NUMBER: 1000208f
The same sites have been able to connect to the databases in the past, just apparently not through TLS 1.2
If I can provide any other info here that would be useful, just let me know and I'll update the thread.
Thanks.
For an SSL connection failure,you may have to look into both sides
(both the client and server side). Please check the sql server and
verify if it with the help of this article on TLS 1.2
Also for the ODBC driver as well,you have to make sure all the components are updated.Refer this msdn .
There is also this powershell script which can be executed to figure out which drivers needs to be updated.
I've put together a site utilising the Stripe payment system.
Upon making a test payment over HTTPS, I get the error:
Stripe no longer supports API requests made with TLS 1.0. Please initiate HTTPS connections with TLS 1.2 or later.
I've made sure all my versions of software are up to date:
PHP Version: 7.0.7
cUrl Version: 7.47.1
SSL Version: OpenSSL/1.0.2h
I've also tested my site itself on https://www.ssllabs.com/ssltest/analyze.html to make sure TLS 1.2 is enabled and functional on the server.
The only thing I can think is if there is possibly an issue with the certificate bundle I have registered in php.ini (CURL curl.cainfo setting), but since Stripe source has a "ca-certificates.crt" already included I wasn't sure if I even needed to set an entry for curl.cainfo in my php.ini file.
Any advice would be massively appreciated. If there is any additional information I can provide that might help, just let me know.
EDIT: Currently using Stripe's PHP Framework v4.1.1 (Latest)
The SSL cert you mentioned is used by your server to respond to incoming requests. What this means is that if I visit your website, as a customer, my browser (Chrome) will try to talk to your server over TLS 1.2 by default as it uses the most secure protocol first. Your server is apparently able to answer requests over TLS 1.2.
The issue we have right now is that when your server contacts Stripe's servers it negotiates TLS 1.0 by default instead of TLS 1.2. Since Stripe is going to deprecate requests made with TLS < 1.2 this means your requests will start failing next year if you don't upgrade.
What I'd recommend here is to talk with your webhost about this so that they can help you look into your setup and ensure that you do support TLS 1.2 requests from your server to Stripe's. Additionally, you can follow the steps outlined at https://support.stripe.com/questions/how-do-i-upgrade-my-stripe-integration-from-tls-1-0-to-tls-1-2 to ensure that your code libraries also support TLS 1.2.
This could also be caused by an outdated version of Stripe's PHP library. They released version 3.19.0 on Friday July 29th which corrected a bug that affected some setups which might explain why you're getting this error even if your host supports TLS 1.2. You may also try updating the Stripe PHP library that you are using to the current version to see if that solves your issue.
Problem was with my local issuer certificate, turns out I was on the right track.
Had to set a default value in my php.ini file for curl_cainfo and that fixed it.
We've developed a PHP cURL based plugin to connect to the Pathable API from Wordpress via Gravity Forms, testing the system it all worked perfectly, however in production the plugin is being hosted on a Rackspace Cloud site environment, apparently they're using curl/7.15.5 however we need curl/7.34 minimum to have support for TLS which is the only protocol that pathable support (SSL being insecure)
We cannot move to another host, we cannot update to the latest version of cURL so we need to re-build the plugin with another solution instead of cURL that's supported by Rackspace Cloud sites. I've spoken with their support but they're not aware of a specific solution so I'm wondering if anyone knows of an alternative that we could use?