Ssl Error Can Not Change to Tls

SSL error can not change to TLS

Try add

CURLOPT_SSL_CIPHER_LIST => 'TLSv1'

to your PPHttpConfig.php file. I had the same issue with you and spent hours to find the solution. This worked for me.

The request was aborted: Could not create SSL/TLS secure channel

I finally found the answer (I haven't noted my source but it was from a search);

While the code works in Windows XP, in Windows 7, you must add this at the beginning:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

And now, it works perfectly.

ADDENDUM

As mentioned by Robin French; if you are getting this problem while configuring PayPal, please note that they won't support SSL3 starting by December, 3rd 2018. You'll need to use TLS. Here's Paypal page about it.

Powershell Invoke-WebRequest Fails with SSL/TLS Secure Channel

try using this one

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri https://apod.nasa.gov/apod/

Windows 7 Could not create SSL/TLS secure channel.} System.Net.WebException

This error occurs on Windows 7 due to the TLS settings. According to Solving the TLS 1.0 Problem, 2nd Edition, TLS 1.2 is Disabled by default. Therefore, it needs to be enabled. Ensure that you've installed SP 1. Then,

Create a restore point

Open Control Panel
Select View by: Small icons
Click System
On left side, click System protection
If protection isn't turned on for the C:, then click Configure to turn it on. Select desired size and click OK.
Click Create to create a restore point
Enter desired name for restore point
Click Create

Go to

Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows and click on Easy Fix

Copy the code/text below to a file that ends in .reg (ex: TLSFix.reg).

Open you're favorite text editor (ex: Notepad)
Copy the code/text below
Save file with a ".reg" extension (ex: TLSFix.reg). Alternatively, save with a ".txt" extension. Then right-click the file and rename it so that it has a ".reg" extension.

Win 7 (64-bit):

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"SecureProtocols"=dword:00000aa8

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000a00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000a00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

Then double click the file to add the entries to the registry. Alternatively, add each of the registry entries to the registry using regedit.

Note: The registry entries above are discussed in Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows and Transport Layer Security (TLS) registry settings.

Resources:

Solving the TLS 1.0 Problem, 2nd Edition
Windows and Supported TLS Versions
Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows
Transport Layer Security (TLS) registry settings
Transport Layer Security (TLS) best practices with the .NET Framework
TLS/SSL Tools and Settings
CA5386: Avoid hardcoding SecurityProtocolType value

Could not establish trust relationship for SSL/TLS secure channel -- SOAP

Thoughts (based on pain in the past):

do you have DNS and line-of-sight to the server?
are you using the correct name from the certificate?
is the certificate still valid?
is a badly configured load balancer messing things up?
does the new ~~server~~ machine have the clock set correctly (i.e. so that the UTC time is correct [ignore local time, it is largely irrelevent]) - this certainly matters for WCF, so may impact regular SOAP?
is there a certificate trust chain issue? if you browse from the server to the soap service, can you get SSL?
related to the above - has the certificate been installed to the correct location? (you may need a copy in Trusted Root Certification Authorities)
is the server's machine-level proxy set correctly? (which different to the user's proxy); see proxycfg for XP / 2003 (not sure about Vista etc)

How to solve Could not establish trust relationship for the SSL/TLS secure channel with authority

As a workaround you could add a handler to the ServicePointManager's ServerCertificateValidationCallback on the client side:

System.Net.ServicePointManager.ServerCertificateValidationCallback +=
    (se, cert, chain, sslerror) =>
        {
            return true;
        };

but be aware that this is not a good practice as it completely ignores the server certificate and tells the service point manager that whatever certificate is fine which can seriously compromise client security. You could refine this and do some custom checking (for certificate name, hash etc).
at least you can circumvent problems during development when using test certificates.

Azure Pipelines local agent failing to connect with SSL error

Enabling below Cyphers with IISCrypto on the server helped us fix the issue

Cipher Suites

TLS 1.2 (suites in server-preferred order)

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128

This from Vijay's solution

Could not establish secure channel for SSL/TLS with authority '*'

Yes an Untrusted certificate can cause this. Look at the certificate path for the webservice by opening the websservice in a browser and use the browser tools to look at the certificate path. You may need to install one or more intermediate certificates onto the computer calling the webservice. In the browser you may see "Certificate errors" with an option to "Install Certificate" when you investigate further - this could be the certificate you missing.

My particular problem was a Geotrust Geotrust DV SSL CA intermediate certificate missing following an upgrade to their root server in July 2010
https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1422

(2020 update deadlink preserved here: https://web.archive.org/web/20140724085537/https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1422 )

Docusign Connect: Error - The request was aborted: Could not create SSL/TLS secure channel

I was able to find this article: https://developers.docusign.com/esign-rest-api/guides/mutual-tls-apache2 and pass this to my server administrator. This was apparently had the missing info they needed to get it working. Not really an answer, but if you are struggling like I was, this will help steer you in the right direction.

Ssl Error Can Not Change to Tls