0

We have a Web API endpoint configured to allow, but not require, client certificates.

We're logging the certificate we receive, then checking to make sure it is what we expect, logging the result, and then either allowing access or returning 403.

The problem is that if the client sends a certificate that isn't signed by a trusted root authority, we don't seem to be getting the certificate at all.

I'd prefer to be able to log what certificate we'd received, and then log that it wasn't signed, then return 403, instead of simply logging that no certificate was supplied.

Is there something I can configure in IIS to allow this?


The comment says that this is usually called a "self-signed certificate", and that's missing the point, so I must not be being clear.

There's no difference between a certificate signed by trusted root authority and a certificate signed by a user except that the public key of the trusted root authority is supposed to have been installed as a trusted root authority by default.

Suppose The user has created his own signing certificate, used it to sign a client certificate, and has attached that certificate to an http request, but has not added his signing certificate to the server's trusted authorities?

What I'm seeing happen is that the certificate is being stripped, so that it looks like, to the endpoint's controller, that no certificate was attached.

This means my server-side logging cannot distinguish between the case where no certificate was supplied or when an untrusted certificate was supplied.

I'd like to be able to log different error messages for the two cases.

jdege
  • 193
  • 9
  • That's usually called self-signed certificates, https://en.wikipedia.org/wiki/Self-signed_certificate, not unsigned. – Lex Li Dec 28 '18 at 04:56
  • Are the logs showing the the sub status error of 16 on the 403? Can you use wireshark to verify the client is sending a client cert for the handshake? – Mass Nerder Jan 02 '19 at 23:02

0 Answers0