This project has moved and is read-only. For the latest updates, please go here.

Client Certificate behind Reverse Proxy: how to prevent network connection from getting closed

Nov 25, 2014 at 11:41 AM
Edited Nov 25, 2014 at 11:42 AM
My ASP.NET Web API OWIN Middleware calls
context.Get<X509Certificate2>("ssl.ClientCertificate") 
for getting a client certificate (if available). However, as soon as my API is behind a IIS Reverse Proxy AND the communication is over HTTPS (between RP and my API) the API call fails because
context.Get(...) 
causes

An operation was attempted on a nonexistent network connection.

In case I pass by the RP or the connection between RP and API is over HTTP it works...
Nov 25, 2014 at 5:14 PM
This sounds like an issue with the reverse proxy. "ssl.ClientCertificate" should no-op for an HTTP connection. For an HTTPS connection it will attempt to comunicate with the client (the RP). It sounds like the RP is resetting the connection because it can't negotiate the client cert. The reset isn't coming from your server, it would just return null if it couldn't negotiate a client cert.
Nov 25, 2014 at 5:18 PM
Are you looking for this? http://technet.microsoft.com/en-us/library/dd443526(v=ws.10).aspx
"Forward encoded client certificate in the following header"
Nov 25, 2014 at 7:26 PM
Hi Tratcher, thank you for helping me!

Actually I do use the ARR-header and this works like a charm. So far so good. However, my API shouldn't only be accessible though the RP but also directly... Because of this I use "ssl.ClientCertificate" as a fallback (in case someone talks directly to the API and provides a client certificate over HTTPS).

So it looks like IIS (RP) has an issue with this? In this case I think I should approach MS for a solution...