Bad Gateway 502.3 error when using ARR in IIS

We are experiencing issues with ARR configuration when trying to proxy requests to an external web site. Our server configuration is as follows:

1. Web server with IIS 7.5 that we control. It runs a few web sites, all via HTTPS only

• https://customer1.muciacio.net
• https://customer2.muciacio.net

2. Our customer's web site, which we cannot control and whose configuration we cannot change. Their domain name, for the sake of this discussion, being https://www.parashka.com

We need our server to accept requests to a specific subdomain that we control, namely https://gateway.muciacio.net, and forward them to the customer's web site https://www.parashka.com. It is also available via HTTPS only.

For this I created new web site node in IIS, bound it to gateway.muciacio.net via HTTPS, and adjusted ARR/URL Rewrite rule as follows:

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="ReverseProxyInboundRule1" stopProcessing="true">
          <match url="(.*)" />
          <action type="Rewrite" url="https://www.parashka.com/{R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>   
</configuration>

And now I am getting HTTP 502.3 Bad Gateway error. Failed request tracing shows also it's caused by the error with code 2147954575 (0x80072F8F), which I believe is ERROR_WINHTTP_SECURE_FAILURE.

Interestingly, if I configure ARR to forward requests to the site on our own server, e.g. replace action entry with this one:

<action type="Rewrite" url="https://customerX.muciacio.net/{R:1}" />

then the error is gone and all works as expected.

On the other hand, if I retarget ARR to some well-known site, say stackoverflow:

<action type="Rewrite" url="https://stackoverflow.com/{R:1}" />

then the same error 2147954575 appears again, which makes me think that the customer's web site is not to blame and that is something wrong at our end.

On the Internet I found a few vague comments pointing to the requirement of having the same SSL certificate on both web servers. However it makes no sense at all in our context since the servers are different domains and controlled by different organizations.

Also please note that our server is Windows Server 2008 R2 (no chance to upgrade soon, can't do much with it)