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.
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 have upgraded to IBM MQ 7.5 to 8.0.
Beforehand I was using SSL. Since SSL is disabled in MQ8. I have to use TLS. But the question is do I need to create the certificate again to use with MQ 8 after upgrading process?
No, the certificate is independent of the protocol used.
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).
I am trying to configure test automation project in UFT 12.02 for IBM Websphere MQ 6.0
I am facing the following error while connecting to MQ Queue Manager
(To run tests with IBM’s MQ client, make sure to install the MQ client on all machines running these tests.)
as per the above error description I need to install MQ client on my machine, but I cannot install it because IBM has been stopped supporting MQ 6.0 accordingly I didn't find it anywhere.
I have configured the same but in IBM RIT (Rational Integration Tester) and it was only required to configure the JAR files (com.ibm.mq.jar & connector.jar)
My question is; Is it applicable in UFT to configure only above two JAR files (just like IBM RIT) or it is necessary to install the MQ 6.0 Client?
And can I test the MQ 6.0 through UFT along with installing MQ 7.0 Client instead of 6.0, taking in consideration that the AUT is IBM Websphere MQ 6.0?
Also if applicable, can anyone provide the MQ Client download URL rather than IBM website?
Prior to V8.0 it was required to install the full client to receive support. Just grabbing the jar files worked but you risked IBM not supporting it if you wanted to open a PMR.
As of v8.0, IBM offers an all-Java client. I just provided the download instructions in another answer so instead of copying them, I'll link to that answer:
WMQ V8 Connection Factory setup on Tomcat using JNDI
One of the reasons this was not previously supported was that the old Java jars didn't have as much diagnostic function built in. IBM relied on the full client install for binary cient-side tracing, test programs, etc. The v8.0 stand-alone jars are really the way to go if you need an all-Java solution.
Note that support is based on the QMgr's license, not the client license (because that's free). If you are running a v6.0 QMgr other than the Linux Itanium version, then either you are paying a LOT of money for IBM Support or are running unsupported. If it is the latter, then you can't open a PMR anyway.
An unpatched v6.0 QMgr is effectively not secure. Even if you have applied the recommended security configurations, enough security-relevant APARS have now been discovered that you should consider an unpatched QMgr as being wide open.
As Tim notes in the comments, any version of MQ Client is supported with any version of MQ QMgr. Head over to the SupportPacs page and look for ones with names like MQC**. Pro tip - If you download a new client, it comes with XA transactionality enabled. No need to go grab the transactional client jar file (which put you out of license compliance anyway).