1

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?

sharptooth
  • 2,739
  • 4
  • 32
  • 40

1 Answers1

3

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.

Crypt32
  • 6,639
  • 1
  • 15
  • 33
  • Suppose the Good Third Party can generate another certificate and specify other parameters for "-sky" and "-eku" (and perhaps some other) makecert parameters. Will using such certificate be more secure for the server side? – sharptooth Oct 18 '16 at 06:55
  • No. Especially, counting that makecert is deprecated, because it uses old and insecure cryptography. – Crypt32 Oct 18 '16 at 13:11
  • What if the client cert key usage is only: `Digital Signature, Key Encipherment, Data Encipherment` but not `Certificate Signing...` how could it do any harm, it could have never been used to sign other certificates.? Just a thought. – Peter Hahndorf Oct 18 '16 at 13:30
  • this may invalidate the chain as issuing certificate is not applicable to sign other certificates (will definitely fail if Basic Constraints extension is missing or is `Basic Constraints: isCA=false`). – Crypt32 Oct 18 '16 at 16:46
  • @PeterHahndorf Does `Digital Signature` make certificate usable for signing code? – sharptooth Oct 19 '16 at 08:54
  • it is required, but not enough. `Digital Signature` enabled bit in combination with `Code Signing` value in the Enhanced Key Usage certificate extension will allow to sign the code. Sole `Digital Signature` bit doesn't allow code signing without proper EKU. – Crypt32 Oct 19 '16 at 14:51