Disabling TLS 1.0 via ServicePointManager may cause side-effects

[HughJeffner]

Specifically this bit of code:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

This setting global to the app domain so if your application connects to other services that do not support TLS 1.1/1.2 then you will get an exception:

System.Net.WebException The request was aborted: Could not create SSL/TLS secure channel.

Not sure if there is anything to be done here but I wanted to make a note of this because it took me several hours of troubleshooting to trace the fault back to this library. I was previously using an older version without the change and updated to the most current version.

I would think if the payment gateway had TLS 1.0 disabled server-side then .NET would use TLS 1.1+ to negotiate the connection but that code was put there for a reason and I am not sure why.

[securesubmit-buildmaster]

Good Morning, Thanks for the note! This scenario was not one we thought of when we made the decision to add the line of code. I will look into this some and see if I can recreate and rectify the issue satisfactorily. Thanks, *Russell Everett* SENIOR DEVELOPER | GLOBAL PAYMENTS INC. <https://www.globalpaymentsinc.com/> T: +1 812.280.8222 x65622 <(812)%20280-8222> | [email protected] <[email protected]> SERVICE. DRIVEN. COMMERCE NOTICE: This Email message is for the sole use of the addressee named above, and may contain confidential information. Any unauthorized review, use, disclosure, distribution or duplication of this message or any attachments is expressly prohibited. If you are not the intended recipient, please contact the sender by reply Email and destroy all copies and backups of the original message.

…

On Thu, Sep 21, 2017 at 9:43 AM, Hugh Jeffner ***@***.***> wrote: Specifically this bit of code: ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; This setting global to the app domain so if your application connects to other services that do not support TLS 1.1/1.2 then you will get an exception: System.Net.WebException The request was aborted: Could not create SSL/TLS secure channel. Not sure if there is anything to be done here but I wanted to make a note of this because it took me several hours of troubleshooting to trace the fault back to this library. I was previously using an older version without the change and updated to the most current version. I would think if the payment gateway had TLS 1.0 disabled server-side then .NET would use TLS 1.1+ to negotiate the connection but that code was put there for a reason and I am not sure why. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKYdUjAhFGZqJBARKLnDGSEj8EdKT3Djks5skmgZgaJpZM4PfVwl> .

[ensemblebd]

I'm encountering this as well.
When submitting payment, even if you specify a multiplicity of connection support, the error is achieved.

System.Net.ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls11 || SecurityProtocolType.Tls12

For me this is presently critical. If I can locate a solution I'll post back. Not sure if anyone else has switched to 1.2?

---

Edit: Resolved by ensuring web.config had a value for targetFramework="4.6.1", default is 4.5.2.
Compilation framework of 4.6.1 results in proper binary compilation with reference to TLS12 property, but web runtime of 4.5.2 doesn't offer that it would seem?
I still have to force the value to Tls12, even though I'd rather have support for multiple.
So I just swap it as a "wrapping execution" for heartland payments.