The Client Certificate Problem

  • Article

Holiday Question #2, from Mathieu:

In Belgium we have a electronic identity card (eid) it contains a certificate for signing and authentication in windows.
After some investigation I found some documents on the microsoft website how I could implement client certificate authentication with the eID on my IIS webapplication. (ASP.NET)
This works very good ! (at the my intranet)
But when I would like to test the same application behind my ISA firewall, it does not work.
The user does not get the prompt from Internet Explorer to select an installed certificate and use this for my website.
How can I change my ISA server that Internet Explorer will be asked to send a certificate and that the certificate give will be read by my IIS server.
For now I use ISA 2000, but I will upgrade if it's working in 2004. But i cannot find any documentation about that subject.

Good question, but the answer won't be quite so good.

For ISA 2004:

  • An ISA Server can use Client Certificates to authenticate its clients.
    • on the client, that's
      • a Certificate
      • with Intended Purposes that include Client Authentication
      • for which the client has an associated private key
  • An ISA Server can use one specific locally installed Client Certificate per publishing rule to authenticate itself to a published Web Server that requires Client Certs
    • it's one to many - all clients using that rule (and meet whatever criteria ISA is enforcing - eg, authentication, IP address, content restrictions) then get to use the same client cert.
  • An ISA Server can't pretend to actually be the client that presented a valid certificate to it, as it has no knowledge of that client's private key.
    • The process of proving identify using a client certificate does not reveal the private key to the server, only that the client can provide evidence that it knows the private key.
    • Contrasted with other authentication protocols:
      • NTLM similarly doesn't reveal the user's secret (roughly equivalent to the private key) to the target server.
      • Basic Authentication gives the target server both the username and the password, in Base64 encoding (which is the next worst thing to plain text), which is why Basic over TLS/SSL (and/or VPN, and/or IPSec) is recommended when it is needed.

So, short version: in this type of scenario, ISA Server is effectively acting as a Man In The Middle (MITM), and the use of client certificates prevents it from working (I don't know enough to claim that it's how it'll always work, but for now, that's my assumption).

You end up with two options:

  • If the client must present its credentials directly to the Web Server, you could use Server Publishing. You lose the application layer inspection benefits of Web Publishing, but the client and server are assured of privacy, as they work directly with each other.
  • If it's acceptable for clients to authenticate to the ISA Server using Certificates, and then for the ISA Server to act on behalf of any authenticated clients to the published Web Server using one common Client Certificate, you could configure the listener for Client Certificate authentication, and configure the publishing rule with the appropriate Client Certificate.

As I'm still on holiday, I'm short an ISA 2000 box to muck around with, so I can't confirm whether the second option exists for that version, but the Server Publishing option definitely* works for both: ISA just sets up a TCP session between client and server, and gets out of the way.

* - as definitely as I can remember without actually being able to look it up. So a "probably definitely", but I wanted to sound confident*.