I used magento v1.9.0.1,i set up my paypal(for testing) setting well, sandbox is off, SSl is off. But still im getting this error: Unable to communicate with the PayPal gateway any help plz?
You are running into the POODLE issue. See the details here: https://www.angelleye.com/paypal-ssl-error-poodle-vulnerability/
Specifically...
If you want to use TLS 1.2 you’ll need to upgrade to OpenSSL 1.0.1 as a minimum, and then you’ll be able to set CURLOPT_SSLVERSION to 6 (TLS 1.2).
If you want TLS 1.2 to be used automatically during SSL requests, you’ll also need to upgrade to PHP 5.5.19+ (this is the ideal solution but many projects are still on older PHP versions).
Related
I've got a windows forms app which is deployed through click once. The app was build with .net 4.7.2 and it uses the HttpClient API to access a couple of rest web services, which are hosted on an internal server. As you might expect, the services can only be accessed through HTTPS and the server is configured to suppport all TLS versions (btw, this is a 2016 windows server).
The intranet client app (ie, the windows forms app) is deployed across several internal sub-networks and everything is working well with the exception of a single PC (which belongs to a specific subnetwork - it's the only PC that is using this particular app). This PC will only be able to consume the services when the HttpClient is configured to use TLS 1.1.
Since we're using internal certificates (we have an internal certificate authority for our AD), I've already checked and the certificate with the public key of the entity is already present on the trusted certificate authorities container of the computer where the secure session can't be established through TLS 1.2.
The PC is running Windows 10 Pro (latest version), so it should support TLS 1.2. I've tried emulating the requests from Fiddler and the truth is that I'll only get the results when I configure it to use TLS 1.1.
Without setting the protocol to TLS 1.1, I can see that Fiddler says that the handshake hasn't been established and the service is never "executed".
Now, according to what I've read, I shouldn't have been getting any problems with the code. In fact, I shouldn't have to specify the TLS version (it looks like Windows 10 Pro has out of the box support for TLS 1.2 and that should be the default for WIndows 10. Since I'm using .NET 4.7.2, it should automatically use the system's default protocol), but the truth is that only using tls 1.1 (not tls 1.2!) allows for the secure channel to be established.
I've tried running the code in other machines and everything works out as expected (I can establish the secure channel with tls 1.1 or tls 1.2 or even let it use the system's default protocol).
Since I'm not really a network guy, can anyone point me in the right direction? Do you guys think this can be caused by a firewall? Any ideas?
I mean, it looks like the PC recognizes the certificate used in HTTPS session (if that wasn't the case, then I wouldn't be able to use TLS 1.1, right?), but it seems like there's something in the way that won't let me use TLS 1.2...
Thanks.
Luis
Check our official guidance for TLS: https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls
If it is one machine problem, I would recommend to create a simple HelloWorld app doing simple request, targeting the same .NET Framework (4.7.2) and then test that on the specific machine vs. other machines. That will tell you for sure if the problem is in your app or in machine/network settings.
I have several services written with ASP.NET 4.5.2 that fetch data from an external web service. These services have worked perfectly without error for a year or so. However, the third-party supplier has recently restricted their API to requests from clients using TLS 1.1 or higher.
Our services have been failing as they are being rejected by the extrnal web service. I have checked the server we use to host our service - Windows Server 2012 R2 - and this has TLS 1.1 and 1.2 configured (I have checked the registry keys). So surely our .NET service requests should default to one of those?
The fact our services are still being rejected suggests we are still sending our requests using TLS 1.0.
How can I check if our services are using TLS 1.1 or higher? How can I enable the services to use TLS 1.1 or higher?
You can use below tool to check the TLS protocols that the client's host name is supporting.
https://www.ssllabs.com/ssltest/analyze.html
Go to this Qualys SSL Labs, enter the client host name (ex: abdc.com).
Once report is generated, scroll down to Configuration section.
You will find the status of TLS 1.0/1.1/1.2/1.3/SSL3/SSL2
To understand the relation between .Net framework & TLS, refer below link.
https://blogs.perficient.com/2016/04/28/tsl-1-2-and-net-support/
The fact our services are still being rejected suggests we are still sending our requests using TLS 1.0.
In this case you are are using TLS as a client, not a server to connect to a remote service.
I have several services written with ASP.NET 4.5.2
There are registry keys you need to change for the .NET Framework 4.5.2 in order for TLS 1.2 to be used. This is documented here in the .NET TLS guide.
Perhaps the easiest thing to do would just be to move to the latest version of the .NET Framework. If that is not possible, you can do as the guide says
Set the SchUseStrongCrypto and SystemDefaultTlsVersions registry keys to 1.
I am facing some issues while connecting to some of the endpoints. For example, in our application, we are using Paypal as one of our payment methods. But Paypal only supports the connection with tls 1.2 protocol.That being said we are using jdk 1.6 in our local, which is at present restricting me for the connection. I know Oracle has released the tls 1.2 support patch for Windows and Unix. But could not find one for mac. I did try the java 6 which is available in apple but that's also failing.
I have set up an WSO2 Identity server in an EC2 instance. I have mapped the carbon.xml entries to this EC2 instance. The WSO2 server is starting up in that IP without any errors.But when i access it , i get a strange SSL error .ideally SSL warning should be coming since i am using WSO2 provided certificates itself and i can go on bypassing it.This is for sample environment so i am not planning to buy certificates
But this error is totally different and there is no way to bypass it.
The error in chrome says
50.200.189.207 uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
I am unable to get rid of this.What could be the cause?
Some environments may have (mis)configured already unsupported ciphers (I had this issue on AWS Linux with OpenJDK as well, not on CentOS with Oracle JDK).
I suggest you to read WSO2 CARBON Configuring TLS
long story short:
open $WSO2IS/repository/conf/tomcat/catalina-server.xml
Locate Connector for TLS (port 9443 with sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" )
add property: ciphers="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"
note: please read the documentation for exact values of the cipher property
And indeed, Oracle JDK is recommended for WSO2 products (as noted in the comments), the JDK vendors may differ in supported ciphers
If it doesn't work, let me know, I will post exactly what I've used for other projects
I am new to tridion and trying to setup a new instance of tridion 2011. I was able to successfully publish all my requests to file system and broker db. Suddenly it stopped publishing and all requests are stuck in "Ready to transport" mode.
I have already gone through many related threads on this forum, but could not sort out the problem. I am using Widows server 2008, with Jre 1.6 (32 bit and 64 bit both installed). Any pointer to finding the issue will be appreciated.
First thing to check is if your transport service is running.
Second thing I would look at is the config files to make sure the transport service is looking in the same directory that the publisher is storing them. Then see if files are being dropped in the transactions folder on the CM machine.
In our environment this issue arose due to a change in the SSL ciphers supported on our Content Deployer server. We are using the SSHFTP transport protocol and for security reasons the RC-4 cipher suite that had been supported by the CD server was no longer supported. We logged a case with SDL support and they issued Hotfix CD_2011.1.2.2350 which adds support for the stronger ciphers.
Unfortunately, the logs gave absolutely no indication of the issue, even with TRACE level logging.
So if you face this issue and you're using SSHFTP and the other solutions don't work for you, maybe this will help.