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?
Related
We have PHP web application that sends SMTP emails via authenticated smtp.office365.com. This has been working for at least a couple of years.
We are using PHP Mailer 5.2. We are forcing the crypto_method to STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT.
Here's the weird thing. About 75% of the time it works fine. The rest of the time it reports SMTP ERROR: Password command failed: 421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2.
Registered Stream Socket Transports is tcp, udp, unix, udg, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2
How is it even possible that it works most of the time. If it were truly a TLS issue I'd expect it to fail 100% of the time.
Same here on Java application.
I've to force TLS v1.2 in SMTP properties.
In my case:
config.put("mail.smtp.ssl.protocols", "TLSv1.2");
Hope you can find the answer.
From Microsoft:
New submission error speedbump to be introduced
We are fully aware that many customers will not have noticed the multiple Message Center posts and blog posts, and are not aware of clients or devices that are still using TLS1.0 to submit messages. With this in mind, starting in September 2021, we will reject a small percentage of connections that use TLS1.0 for SMTP AUTH. Clients should retry as with any other temporary errors that can occur during submission. Over time we will increase the percentage of rejected connections, causing delays in sending that more and more customers should notice. The error will be:
421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2. Visit https://aka.ms/smtp_auth_tls.
We intend to make a final announcement when we are ready to make the change to disable TLS1.0 and TLS1.1 for SMTP AUTH for the regular endpoint.
Additional documentation can be found here: Opt-in to Exchange Online endpoint for legacy TLS clients using SMTP AUTH
Exchange Transport Team
I found that upgrading the PHP version my server was running helped solve this issue. I was previously running version 5.* and despite trying to force the script to use a newer version of TLS it was still running into the speedbump MS have put in place. Upgrading my version of PHP to version 7.4 solved this issue and I have seen no rejected emails since.
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.
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.
The site that connect sandbox paypal works , until recently
it can connect will curl
but when it send the request at the second time
it show the error of
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
I have tried some reference online and set the SSL SHA-256 cert of it but it return same error. Other suggest switch to TLS at the curl connection but it may not perfered as there are many project I have handled.
Are there any suggestion to connect sandbox paypal with SSLv3? Thanks for helping.
You'll have to switch the cURL request to use TLS 1.2 in order to use the PayPal sandbox. I'm in the same boat, and there's no way around it, unfortunately. They just activated the change on the sandbox environment a few days ago.
https://devblog.paypal.com/upcoming-security-changes-notice/
I'll add some extra info on this since the first answer doesn't really cover all of the important points.
Paypal has started rolling out some upgrades, the sandbox now requires TLS 1.2 for all requests, and production systems will also require this from June 2016 onwards.
To support this you will need to:
Ensure your server has OpenSSL 1.0.1 or above (which is when TLS 1.2 support was added).
openssl version will show you your version number.
Once you meet that criteria, in your PHP code you can force the SSLVERSION to TLS 1.2 with the following command:
curl_setopt($curl, CURLOPT_SSLVERSION, 6);
Or if you want a less hacky solution, it is possible to have the correct SSL version kick in automatically during the handshake, where the client and server compare available ciphers to find a common protocol. You appear to be using PHP + curl, so you'll need PHP 5.5.19+ and curl 7.29+ for this to take place.
I have similar problem with error 14077410 and SSL3. I upgrade my PHP server from 5.4 to 7.0 and error disappear.