Disabling TLS 1.0 is required to pass PCI scans. I’ve done this before, and it’s fairly trivial in most cases, but when I disabled it on my e-commerce server, VevoCart started complaining. The UPS shipping estimate web service call failed, as well as our credit card processing system (which I didn’t find out about until later).

The outbound call to UPS fails because it defaults to TLS 1.0. The simple workaround was to use disable TLS 1.0 only for incoming connections, and leave the outgoing ones untouched (IIS Crypto is free, and makes this super easy).

Perfect - that’s probably the same issue our credit card processing experienced too, right? Wrong.

Credit Card processing was still throwing an error, which initially made no sense, since that’s obviously an outbound call. I knew it was related to the TLS change I’d just made, because I could enable TLS 1.0, and it’d work fine.

Taking a step back, it’s easy to see why this failed. When a transaction takes place in VevoCart’s WebApp, it makes a web service call - not an outbound one to the credit card processor, but an internal one to the VevoCart Payment Application, which is setup as a virtual directory on the same server. The VevoCart Payment App then makes the outbound web service call to the credit card processor.

The internal call is where the breakdown happened. When I disabled TLS 1.0 for incoming connections, the call to the Payment App (from the WebApp) failed, even though the call originated from the same server. Once I figured that out, the fix was simple. Force VevoCart’s code to use TLS 1.1 or 1.2

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

You’ll need to add this wherever WebRequests are made.