The title says it all.
There are certainly ways to do hosting specific tricks - but the concept of client certs should be baked into Web API itself. This is important for security scenarios.
From an OM point of view this logically belongs on HttpRequestMessage (in one or the other way).
Comments: TLS - transport layer or layer 4 (of 7). We all us.e SSL for TLS. I think the comment means that I would see some message-layer (layer7) protocol exchanges, including the client cert and associated signatures. These are presumably formatted similarly to those used in ws-security-enabled remote operations. What I wont see is a client cert exchanged in the SSL handshake messages (down at layer 4). If this is true, then it doesn't solve my problem. This sample, being probably a variant of the classical WCF layer 7 cert-related sample, does showcase a receiving party processing client certs ... without the cert (or its root) being pre-registered in a receiver-side cert store. And the latter is my test. I just hoping for the same to be true for "SSL client" certs. Of course I keep hoping in vain, a the handling of true SSL client certs requires kernel involvement via https.sys (and that whole arrangement just assumes cert stores). The title confused me. I read "SSL client" cert, not SSL "Client cert". Client certs at layer 7 over a server-side layer 4 SSL/TLS tunnel with "SSL cert" is not new. I also assumed a WebAPI project was going to be a lightweight design, suiting rest and browser usage etc. Of course, true layer "SSL certs" citied by API consumers acting as layer 4 SSL clients are lightweight, having no messaging overhead from the layer 7 cert/sig/signaling.
There are certainly ways to do hosting specific tricks - but the concept of client certs should be baked into Web API itself. This is important for security scenarios.
From an OM point of view this logically belongs on HttpRequestMessage (in one or the other way).
Comments: TLS - transport layer or layer 4 (of 7). We all us.e SSL for TLS. I think the comment means that I would see some message-layer (layer7) protocol exchanges, including the client cert and associated signatures. These are presumably formatted similarly to those used in ws-security-enabled remote operations. What I wont see is a client cert exchanged in the SSL handshake messages (down at layer 4). If this is true, then it doesn't solve my problem. This sample, being probably a variant of the classical WCF layer 7 cert-related sample, does showcase a receiving party processing client certs ... without the cert (or its root) being pre-registered in a receiver-side cert store. And the latter is my test. I just hoping for the same to be true for "SSL client" certs. Of course I keep hoping in vain, a the handling of true SSL client certs requires kernel involvement via https.sys (and that whole arrangement just assumes cert stores). The title confused me. I read "SSL client" cert, not SSL "Client cert". Client certs at layer 7 over a server-side layer 4 SSL/TLS tunnel with "SSL cert" is not new. I also assumed a WebAPI project was going to be a lightweight design, suiting rest and browser usage etc. Of course, true layer "SSL certs" citied by API consumers acting as layer 4 SSL clients are lightweight, having no messaging overhead from the layer 7 cert/sig/signaling.