I'd like to limit access to some of my REST api, such that only bidirectional SSL/TLS connections are accepted, where the "other side" matches a detailed, restricted, whitelist.

Is this something that's easily supported by the microsoft stack, as part of their MVC implementation - and, if it is, is there an example of how I might use it?

As a nice bonus, it would be cool if i can check the incoming certificate matches a list of domains (ie, check that the cert is issued to a domain that's on my white list, and that the connection is coming from that domain, as opposed to whitelisting some ip addresses - so i can allow the certs to change between trusted authority sources, and the ip addresses to change arbitrarily).

  • What do you mean by "bidirectional connections"? Do you mean the case where both the server and client would need to authenticate themselves with their own certificate?
    – Daisetsu
    Feb 8, 2014 at 4:07

2 Answers 2


Your question is rather unclear because every TLS connection is, by nature, bidirectional: it allows bytes to flow in both directions. I suppose that you mean connections where both the client and the server show a certificate.

On the client side, the server's certificate is accepted if all of the following hold:

  • The server's certificate can be validated, i.e. put at the end of a chain of certificates, that begins with a trusted root, and all the names, signatures and various extensions match along the chain.
  • The revocation status of all these certificates can be ascertained to be "not revoked" with fresh enough information (obtained from CRL and/or OCSP responses).
  • The expected server name, i.e. the name which appears in the URL that the client uses, appears in the server's certificate (in the Subject Alt Name extension, as per RFC 2818).

By default, the .NET client code will rely on the set of trusted roots valid for the account under which the client code runs; this is a fusion of the "Root" certificate stores for the "current user", "local machine" and "enterprise".

On the server side, the client's certificate can be validated by IIS. In that case, IIS has two modes:

  • clientCertificateMappingAuthentication: the client certificate is validated against the set of trusted roots of the server; the issuing CA (the one which immediately signed the client certificate) must be part of the enterprise NTAuth store; and then the UPN is extracted from the client certificate and looked up in the local Active Directory server. The part about the "NTAuth" store is where you can restrict client certificates.

  • iisClientCertificateMappingAuthentication: IIS does the job, not the AD server (i.e. that's what you do if the server is not part of a domain). After validation against trusted roots, IIS can do a "one-to-one mapping" in which a client certificate will be accepted only if it is bit-to-bit identical to a certificate registered into IIS, and then mapped to a specific identity.

There are many configuration options. And you can programmatically override most parts of the process. For instance, see this page for how to configure on the server a custom class for validating client certificates; with such a class, you can do everything you wish to do (but beware, you can also do some very weak things, such as trusting the certificate on face value without any validation).

  • The linked article is specific to WCF and wouldn't work at the site/iis/mvc level. At that point you really need to use a httpmodule and hook the postauthenticated event and verify the client cert via 401/403/200 responses.
    – Steve
    Feb 8, 2014 at 19:04

Here is how I accomplished this using IIS6, it should still be supported in later versions.

  • Make sure server certificate is installed and working
  • Make sure the client certificate root CA and any intermediates are installed on the server in the system store
  • Under "Secure Communications":

    • Enable Require Secure Channel (SSL)
    • Require Client Certificates
    • Enable Client Certificate Mapping
    • Under the Edit button add a 1-to-1 mapping using the Client Certificate(s) you would like to allow access. You will have to use a local windows account with proper permissions. I used the local anonymous user account by extracting the password using Metabase Explorer.
    • You can optionally use the certificate trust list to build a list of trusted root CA's that the client certificate must be issued from
  • Back out to Authentication and Access Control, Disable Anonymous access and Integrated Windows authentication

With this setup the request will be rejected if no client certificate is presented. If a client certificate is presented that does not match one of those in the 1-to-1 mapping then the request will be rejected since anonymous access is disabled and it could not be mapped to a valid user.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .