Client Certificate Authentication (Part 1)
Published Jan 23 2019 02:05 PM 157K Views
Microsoft

Author: Kaushal Kumar Panday (kaushalp@microsoft.com)

 

SSL/TLS certificates are commonly used for both encryption and identification of the parties. In this blog post, I’ll be describing Client Certificate Authentication in brief.

Client Certificate Authentication is a mutual certificate based authentication, where the client provides its Client Certificate to the Server to prove its identity. This happens as a part of the SSL Handshake (it is optional).

Before we proceed further, we need to understand

  • What is a client certificate?
  • What is authentication & why do we need it?
Client Certificates

Client Certificate is a digital certificate which confirms to the X.509 system. It is used by client systems to prove their identity to the remote server. Here is a simple way to identify where a certificate is a client certificate or not:

  • In the Details tab, the certificates intended purpose has the following text:
    Proves your identity to a remote computer
  • Verify that the Enhanced Key Usage field of the certificate has the OID set to (1.3.6.1.5.5.7.3.2).

Below is a screenshot of a sample Client Certificate:


Refer RFC 5246

Authentication & Authorization

In Computer Science, Authentication is a mechanism used to prove the identity of the parties involved in a communication. It verifies that “you are who you say you are“. Not to be confused with Authorization, which is to verify that “you are permitted to do what you are trying to do“.

There are several types of authentication. Here is a list of authentication widely used on IIS (in no specific order:(

  • Anonymous Authentication (No Authentication)
  • Basic Authentication
  • Client Certificate Authentication
  • Digest Authentication
  • Forms Authentication
  • NTLM
  • Kerberos
  • Smart Card Authentication
NOTE: As the SSL Handshake happens before HTTP communication, Client Certificate Authentication takes the highest precedence over any other type of authentication that takes place over HTTP protocol.

KerberosClient Certificate Authentication and Smart Card Authentication are examples for mutual authentication mechanisms. Authenticationis typically used for access control, where you want to restrict the access to known users. Authorization on the other hand is used to determine the access level/privileges granted to the users.

On Windows, a thread is the basic unit of execution. Any task performed by the user is executed by the thread under the context of a specific account/identity. Authentication is one of the ways used to determine the thread identity, whose privileges will be used by the thread for execution.

Client Certificate Authentication in SSL/TLS Handshake

I have already discussed SSL Handshake in one of my blog posts. Browse to:
http://blogs.msdn.com/b/kaushal/archive/2013/08/03/ssl-handshake-and-https-bindings-on-iis.aspx

Here is a screenshot describing the SSL/TLS Handshake:


  • Client sends CLIENT HELLO as described in the above image
  • Upon receiving the CLIENT HELLO, if the server is configured for Client Certificate Authentication, it will send a list of Distinguished CA names & Client Certificate Request to the client as a part of the SERVER HELLO apart from other details depicted above.
  • Upon receiving the Server Hello containing the Client Certificate request & list of Distinguished CA names, the client will perform the following steps:
    • The client uses the CA list available in the SERVER HELLO to determine the mutually trusted CA certificates.
    • The
      client will then determine the Client Certificates that have been issued by the mutually trusted Certification Authorities.
    • The client will then present the client certificate list to the user so that they can select a certificate to be sent to the Server.
NOTE:

 

  • On the Client the Client Certificates must have a Private Key. If absent, then the certificate is ignored.
  • If the server doesn’t provide the list of Distinguished CA Names in the SERVER HELLO, then the client will present the user with all the client certificates that it has access to.
  • Upon selection, the client responds with a
    • ClientKeyExchange message which contains the Pre-master secret
    • Certificate message which contains the Client certificate
      (Doesn’t contain the private key).
    • CertificateVerify
      message, which is used to provide explicit verification of a client certificate. This message is sent only if the Client Certificate message was sent. The client is authenticated by using its private key to sign a hash of all the messages up to this point. The recipient verifies the signature using the public key of the signer, thus ensuring it was signed with the client’s private key. Refer RFC 5246 for more details.
  • Post this Client & Server use the random numbers and the Pre-Master secret to generate symmetric (or Master) keys which will used for encrypting & decrypting messages for further communication.
  • Both respond with ChangeCipherSpec indicating that they have finished the process.
  • SSL Handshake stands completed now and both the parties own a copy of the master key which can be used for encryption and decryption.
Design Problems

We know that the server sends the list of Distinguished CA names as a part of SERVER HELLO. The RFC never mandates the list of Distinguished CA Names should contain Root CA or Intermediate CA certificates. Here is a snippet of this section defined in the RFC5246:

certificate_authorities

 

A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. These
distinguished names may specify a desired distinguished name for a
root CA or for a subordinate CA; thus, this message can be used to
describe known roots as well as a desired authorization space. If
the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary

Refer the below blog post for information on Root & Intermediate CA certificates:
http://blogs.msdn.com/b/kaushal/archive/2013/01/10/self-signed-root-ca-and-intermediate-ca-certifica...

This can lead to a problem where few systems require Root CA‘s while few require Intermediate CA‘s to be present in the list sent in the SERVER HELLO. This makes the communicating parties incompatible on certain occasions.

Both the implementations are debatable. On one hand the list sent by the server cannot exceed a certain limit (on windows the size is 12,228 bytes). If exceeded, the auth will fail. The list of Intermediate CA’s always exceeds the list of Root CA by 2-3 folds or even higher. This is one of the reasons why some systems send the ROOT CA’s in the list of Distinguished CA Names. On the other hand, the Intermediate CA names are readily available in the client certificate provided by the user, so it makes it easier during the certificate chain validation, therefore some systems prefer this over the previous one. Both have their own merits.

One example I have personally encountered is Apple‘s Safari browser communicating to a site hosted on IIS 7 or higher which requires Client Certificate for authentication. Safari expects a list of Intermediate CA‘s in the SERVER HELLO. On the other hand, IIS sends only Root CA‘s in that list. As a result the authentication fails as the client is unable to provide a client certificate to the server.

A solution to the above problem is to configure IIS to not send any the CA list in the SERVER HELLO. To achieve this follow the Method 3 described in the support article below:
https://support.microsoft.com/en-us/kb/933430/

The above article requires you to add a registry key, SendTrustedIssuerList, which is set to 0.

As a result the server doesn’t send any list to the client, but requires it to pass a client certificate. The client will present the complete list of client certificates to choose from and it will proceed further as expected.

NOTE: In Windows Server 2012 and Windows 8, changes were made to the underlying authentication process so that:

 

  • CTL-based trusted issuer list management is no longer supported.
  • 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) instead of 1.
  • Compatibility to previous versions of Windows operating systems is preserved.

Further read: https://technet.microsoft.com/en-in/library/hh831771.aspx

Author: Kaushal Kumar Panday (kaushalp@microsoft.com)

6 Comments
Copper Contributor

Hi, I think "The client will then present the client certificate list to the user so that they can select a certificate to be sent to the user" should be "The client will then present the client certificate list to the user so that they can select a certificate to be sent to the server"

 

 
Copper Contributor

links mentioned above do not work

Copper Contributor

I have a MS AD server configured for LDAPS. I want to know where on the server can I play around with the client certificate authentication settings. Right now the server is configured to ignore any client cert validation error, or even when no cert is presented by a client to the AD server over LDAPS. The connection goes on without fail. I want to enforce something corresponding to this in OPENLDAP.

12.2.1.8. TLSVerifyClient { never | allow | try | demand }

This directive specifies what checks to perform on client certificates in an incoming TLS session, if any. This option is set to never by default, in which case the server never asks the client for a certificate. With a setting of allow the server will ask for a client certificate; if none is provided the session proceeds normally. If a certificate is provided but the server is unable to verify it, the certificate is ignored and the session proceeds normally, as if no certificate had been provided. With a setting of try the certificate is requested, and if none is provided, the session proceeds normally. If a certificate is provided and it cannot be verified, the session is immediately terminated. With a setting of demand the certificate is requested and a valid certificate must be provided, otherwise the session is immediately terminated.

Copper Contributor

@rahulf50 Isn't it that only the client need to validate if the ldap server he is connecting is legit? The client doesn't need to identify itself to the AD server. I could be wrong. 

 

So each user of the client machine needs to generate csr for that machine then the CA admin would generate the required certificate along with its private key? If there are thousands of client machines how is it done?

Copper Contributor

@JanuBar In answer to your question I believe this is the documentation you are seeking.

Configure Group Policy to Autoenroll and Deploy Certificates

Copper Contributor

We are setting up AD authentication in our VPN (Cisco MX AnyConnect), its working fine until we enabled a certificate based on the Workstation template from our Windows CA. Self-signed certificate in test is working. We need guidence regarding how to configure the Workstation template for Client Certificate Authentication.

 

*** From client ****

Date : 08/22/2023
Time : 12:05:14
Type : Error
Source : csc_vpnapi

Description : Function: COpenSSLCertificate::VerifyKeyUsage
File: C:\temp\build\thehoff\Quicksilver_MR20.384855878117\Quicksilver_MR2\vpn\CommonCrypt\Certificates\OpenSSLCertificate.cpp
Line: 1865
Invoked Function: COpenSSLCertUtils::VerifyKeyUsage
Return Code: -31391724 (0xFE210014)
Description: CERTIFICATE_ERROR_VERIFY_KEYUSAGE_FAILED:The certificate did not contain the required Key Usages

 

******** From certificate  in norwegian ***

Enhanced Key Usage (1.3.6.1.5.5.7.3.2)

Digital signatur, Ikke-avvisning, Nøkkelchiffrering (e0)

Co-Authors
Version history
Last update:
‎Dec 12 2021 08:56 PM
Updated by: