End of Transport Layer Security (TLS) 1.0 Support

Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).

• For inbound communications (entering the gateway), we already support TLS 1.2. Please note that the system is backward compatible and we do still support previous version of TLS for now. However it is strongly recommended that you upgrade to TLS 1.2 as soon as possible.
• For outbound communications (coming out of the gateway), TLS 1.2 will be available in our TEST and PROD environment as of April 2017. As of then you are encouraged to upgrade as soon as possible to TLS 1.2 and let us know if you encounter any issue.

Ingenico ePayments requires all merchants to upgrade their security protocol before the end of May.

If you use our e-Commerce Hosted Payment Page product, the transactions are initiated from this product. Therefore there is not impact for the gateway inbound communications. However if you have implemented any of the outbound communications (such as the post-sale or offline status changes), you need to upgrade to TLS 1.2.

If you use our DirectLink  or automatic Batch server-to-server products, there is an impact on the inbound communications and you need to upgrade to TLS 1.2.
Moreover if you have implemented any of the outbound communications (such as the post-sale or offline status changes), you also need to upgrade to TLS 1.2.

The following is a list of operating systems and framework compatible with TLS 1.1/1.2, each containing a link explaining the configuration steps:

Windows OS

Windows OS	TLS 1.1/1.2
Windows Vista/Windows Server 2008 (and earlier)	Not supported
Windows Server 2008 (SP2)	Update in order to support https://support.microsoft.com/en-us/help/4019276/update-to-add-support-for-tls-1-1-and-tls-1-2-in-windows
Windows 7 (SP1)/Windows Server 2008 R2 (SP1)	Update in order to support https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
Windows 8/Windows Server 2012	Enabled
Windows 8.1/Windows Server 2012 R2	Enabled
Windows 10/Windows Server 2016	Enabled

.NET Framework

.NET Framework	TLS 1.1/1.2
.NET Framework 3.5 and earlier	Not supported
.NET Framework 3.5 (SP1)	Workaround https://support.microsoft.com/en-ca/help/3154520/support-for-tls-system-default-versions-included-in-the-net-framework
.NET Framework 4.0	Workaround https://blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support/
.NET Framework 4.5	Supported https://blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support/
.NET Framework 4.6 and above	Enabled
Windows 10/Windows Server 2016	Enabled

More information can be found in the following official publications:

• Important update from the PCI Security Standards Council regarding the extension of the deadline - https://www.pcisecuritystandards.org/pdfs/Migrating_from_SSL_and_Early_TLS_-v12.pdf
• PCI DSS version 3.1 - https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf
• PCI DSS version 3.1 - Summary of Changes: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1_Summary_of_Changes.pdf
• PCI DSS version 3.1 - Information Supplement: https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information_Supplement_v1.pdf
• Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (National Institute of Standards and Technology) -http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295

If the cardholder uses a deprecated browser, based on TLS 1.0, the payment page will not be displayed. There will be no specific warning on the issue. The cardholder will have to upgrade to a newer web browser.

TLS 1.1 will not be deprecated in the near future and can therefore be used. However, for security reasons, we do recommend to always use the latest version of the protocols, and therefore advise to upgrade to TLS 1.2.

In order to test your implementation you are welcome to use external tools such as https://www.howsmyssl.com.

If you are using HTTP post-sales you might be impacted. The following steps will help you identify if you are compatible with TLS 1.2 or not.

Step 1: Find your post-sale url.

For static URL

1. Go to your Ingenico ePayments back office
2. Click on “Configuration”
3. Click on “Technical Configuration”
4. Click on “Transaction Feedback” 
              
5. In this view, you will find the static URLs that are used in your post-sale       

For Dynamic URL
Ask your integrator/webmaster to give it to you or ask him to review this guide.
Step 2: Test your URL

1. Go to the sslLabs website https://www.ssllabs.com/ssltest/
2. Enter your post-sale URLs
3. Click on Submit (You should get a summary after a few seconds)
4. Scroll down to Configuration/Protocols and ensure you support TLS1.2
5. Ensure you also support other ciphers than TLS_RSA_WITH_3DES_EDE_CBC_SHA

Step 3: Results are bad. What should I do?

• If you got a result where you don't support TLS 1.2
• If the only cipher suite supported is TLS_RSA_WITH_3DES_EDE_CBC_SHA

You should contact your integrator/webmaster/infrastructure engineer explaining the situation. They should be able to help you getting up-to-date.

The PCI council requires Payment Service Providers like Ingenico ePayments to depreciate older protocols that are no longer considered secure. This means that post-sale exchanges using TLS 1.0 will be considered as not secure by our payment engines and will fail.

If the cardholder uses a deprecated browser or old device that does not support the TLS 1.1 or TLS 1.2, security protocol, the payment page will not be displayed. There will be no specific warning on the issue. The cardholder will have to upgrade to a newer web browser.
As a merchant, you could mitigate the risk of lost transactions by advising users to upgrade their browsers.
The Wikipedia page on TLS provides a complete and comprehensive overview of which browser versions and devices support which security protocols. https://en.wikipedia.org/wiki/Transport_Layer_Security

Make a test transaction
Step 1: Setup your test account (You can skip this step if you already have one)

1. Create a test account and set it up to be connected to your test environment.
2. Set your POST-SALE URL

i. Static URL

 

iii. Dynamic URL: Ask your integrator/webmaster to give it to you or ask him to review this guide.

Step 2: Perform a test

You can use the Back Office test pages to perform a test transaction or your usual means (ask your integrator/webmaster). Then you can confirm that the postsale has been received and treated normally. 

Step 3: Troubleshooting (It's not working)

• Please ensure your server (accepting the postsale requests) is compatible with the latest IETF standards (https://www.ietf.org)
• If not you should probably make some updates on your servers
• We are using internally the HTTPClient .Net library, please use these examples to debug your system
• Microsoft documentation: https://msdn.microsoft.com/en-us/library/system.net.http.httpclient(v=vs.110).aspx

Examples https://docs.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client