Worldpay Gateway Callback Issue


My web server is (include version): IIS 8
The operating system my web server runs on is (include version): Windows 2012

I’ve migrated a website to another windows server and noticed that the callback from Worldpay payment gateway now displays an error “failed CAUSED BY Remote host closed connection during handshake”.

I know it is an SSL issue as removing the “https” from the callback URL, makes it work as expected.

I am suspecting that, as there are two sites on the server and this server only has one ip address (the old one had one per site), that Letsencypt has used SNI to issue the certificate?

I suggest this because I read several old posts on other sites saying that they’ve found Worldpay doesn’t like SNI based certificates. Worldpay support didn’t seem to know either way.

Has anyone had any experience on this, or have any suggestions?

Would a second IP address, then assigning one to each site, then re-issueing letsencrypt certificate fix this?
Second IP addresses are not that cheap from my current host, but needs be.



I’m not sure how your payment gateway do, but you can definitely use a second IP to avoid the SNI issue.

You won’t need to reissue tls certificate to use dedicated IP. Just use IP based vHost can solve this problem.

Thank you


Server Name Indication was introduced in IIS 8.0.
But it might be easier said than done (properly).
If you can, consider inserting a reverse proxy (which can be run on the same server).
Route all incoming HTTP & HTTPS connections to the proxy (on separate internal IP - to simplify matters).
Proxy SNI name one to internal IP one.
Proxy SNI name two to internal IP two.
Proxy SNI name three to internal IP three.

There is no shortage nor cost for internal IPs.

In short, delegate the SNI process to the proxy and just use IIS as if it was only IP based (without the added cost of real IPs).


Apart from the possibility of SNI causing trouble (though it really shouldn’t cause a failed handshake), it may also be that Worldpay are enforcing TLS 1.2 connections (as per the latest PCI DSS it is required from 30 June 2018), so check that your server is serving TLS 1.2 clients.

This isn’t possible. If the client does not send a TLS SNI Extension, then it is impossible to know what host the request is destined for without peeking at the HTTP request. However, this can’t happen, because the client will not even begin sending an HTTP request until it has verified the certificate in the ServerHello frame. Classic chicken and egg problem.


I’ve added a new IP address and dedicated each site to a separate IP. Tried the tests at SSL labs, and still the check says "This site works only in browsers with SNI support. ". I revoked that ceriticate and re-issued a new one, still the same result.

The certificate is up to and including TLS 1.2 (as Wordpay are enforcing this).

SNI based certificate seems to be issued no matter whether an dedicated IP address is used or not?

Any other ideas?


Can’t believe I didn’t notice it, but there’s a new checkbox in IIS 8 for each binding which says “require Server Name Indication”. Once I’d unchecked that, the SSL check no longer said "This site works only in browsers with SNI support. "

I presume that you can uncheck this only when you have one IP per site.

Will check if this now fixes the Worldpay issue tomorrow.


You can uncheck it when all connections to the IP are expected to reach only one site.
So that any name that resolves to that IP or even the IP itself will return the same content.
SNI makes one IP available to many sites - think shared hosting.
Using SNI makes the default IP connections an unknown - which of the shared sites should respond to direct IP connections? Default = none of them.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.