4

my company developed a .net based application (relying on SChannel) aimed at performing TLS1.2 mutual authentication between 2 instances of the same SW, one acting as client and the other one as server in the TLS1.2 mutual authentication session.

Both client and server SW instances were deployed on different Windows OS servers (2008R2 and 2012R2).

We have tested successfully the application on a Windows Server 2008 R2 OS (both "client" and "server" SW instances running on WIN 2008R2 OS); in that case, the Server provides, within the initial "Server Hello" message of the TLS1.2 handshake under the "Certificate Request" section, a list of "Distinguished Names" which matches the content of the Trusted Root CA Certificate Store (Local Computer) running on that same server, as per TLS1.2 RFC standard.

However, when running the same application (using the same set of certs) on a Win2012 R2 OS environment, during the Server Hello message, the Certificate Request part keeps returning an empty DN list (that is, 0 certificate being listed), even if the same set of Trusted Root CA are available in the Trusted Root CA Store (Local Computer).

When the SW acts as client in the TLS1.2 handshake, running on either 2008R2 or 2012R2, the SW is able successfully to use a client-authentication certificate made available / installed under the Local Computer -> Personal -> Certificates.

I was not involved in the code development of the program cryptographic feature, but I have the feeling that I might just be missing some additional settings introduced at OS level when moving from 2008R2 to 2012R2 rather that having a SW issue - hence I was wondering if anyone could suggest possible OS settings that might need to be adapted.

Thank you

Improve this question
4
  • Some leads to check: 1. Do you have extendedKeyUsage field set to something (e.g. Client Authentication purpose) that would prevent it from being used for server authentication? 2. Take a look at your cipher list, are you by any chance end up negotiating anon or export cipher?
    – Kirill Sinitski
    Dec 23, 2016 at 15:41
  • Thank you for your feedback - checked 1. and 2. and both points are ok. Any additional leads that I could check ?
    – Ottootto
    Dec 23, 2016 at 22:29
  • How big is the list of distinguished names returned on Win 2008R2? Is it really the whole list of your trusted authorities?
    – John Blatz
    Dec 24, 2016 at 5:57
  • Is this just an anomaly on Win2012 or does mutual auth actually fail?
    – StackzOfZtuff
    Dec 24, 2016 at 8:56

1 Answer 1

Reset to default
5

Expected behavior on Win2012. Leave as is, or force via registry.

I have never configured client cert auth on any IIS but I think I found out what's wrong here: "SendTrustedIssuerList" defaults to OFF in Win2012.

The server side of mutual TLS auth works differently in Win2012. Namely: The behavior to send the Trusted Issuer List by default is off: Default value of the SendTrustedIssuerList registry key is now 0 (off by default) (Archived here.) It seems that you could do this manually in earlier Windows server versions, but now it is the default.

Additionally what Win2012 now seems to do is a lookup process across three certificate stores for acceptable client certificate CAs (Archived here.). (Namely you no longer need the cumbersome process of generating the list of acceptable CAs via a "CTL"/"Certificate Trust List" and instead just move/copy acceptable CAs into new certificate stores.)

HOWEVER: Even though such a "Trusted Issuer List" must be generated INTERNALLY, it is NOT sent out EXTERNALLY to the client. And that is because SendTrustedIssuerList now defaults 0.

So the solution seems to be to:

  1. Check that the three-store-process is correctly set up server side.

And for interactive applications:

  1. If you insist on sending the acceptable CAs to the client then force SendTrustedIssuerList to 1. But then expect client Apple Safari to fail.. (I expect this to be a non-issue, as this would already have happend in your Win2008r2 setup and you didn't mention this.)

  2. If you do not insist on sending the acceptable CAs to the client, then leave as is. But expect a larger "choose your client cert here" dialog box on your clients, as you no longer offer them any hints about acceptable client certs. (But then again client browsers usually don't really have that many client certs to choose from. So the list will likely be short.)

And for non-interative applications, as in your case:

  1. Either to force the client side to supply the right client cert without getting the hint.

  2. Or to force the server to send the hint and the client side to take the hint.

Improve this answer
3
  • 1
    Thank you for the extensive and highly useful technical description. It turned out this was exactly the root cause of the issues we have been seeing so far. Thanks again for your excellent contribution.
    – Ottootto
    Dec 25, 2016 at 11:55
  • @Carlo: Okay, great! What did you end up doing with your app?
    – StackzOfZtuff
    Dec 25, 2016 at 14:28
  • 2
    basically just modified the win2012r2 os registry according to the provided description and verified via wireshark that TLS1.2 mutual auth is now properly working - the server is now returning a list of DN during the TLS handshake phase contained in the "Server Hello / Certificate Request" message part. So no SW changes needed at Application layer as the application is entirely relying on SChannel for TLS / SSL implementation.
    – Ottootto
    Dec 27, 2016 at 5:24

You must log in to answer this question.

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