I'm trying to setup client certificate authentication in an ASP.NET MVC3 application running in IIS 8. The client (Good Third Party) uses a self-signed SSL certificate to authenticate himself and my application knows the thumbprint in advance and checks that the request has a proper certificate with it.
It doesn't work out of the box - IIS rejects requests with HTTP 403.16 (client certificate untrusted).
I experimented a lot and it looks like if I add the client certificate to either "Root" (Trusted Root Certification Authorities) or "Auth Root" (Third-Party Root Certification Authorities) certificate stores then requests pass through to the application code - IIS now trusts the certificate and accepts requests. So adding the certificate into one of those stores "makes it work".
The problem is I'm not sure what other effects such change may have. Suppose the Good Third Party loses their private key part of the certificate and some Bad Third Party abuses it - what can they do except posing as Good Third Party? Maybe they can sign a code package which my system will then trust? Maybe they can issue a site certificate and make my system trust their malicious site?
Which store do I add the client certificate so that I minimize the unexpected security risks?
Answer
You cannot solve your problem without security risk. The only option for you is to install the certificate in the Local Machine\Trusted Root CAs store. As the result, this 3rd party certificate will be trusted by all applications that use Windows Cert Store. If it is CA certificate, then all child certificates below that root will be trusted on your system.
If you run your own PKI, then you can increase the security by performing qualified subordination of that certificate. With qualified subordination you will be able to set various types of constraints under which the certificate is trusted or not.
No comments:
Post a Comment