DOCUMENT:Q257586 10-OCT-2001 [iis] TITLE :Description of Client Authentication Process During SSLHandshake PRODUCT :Internet Information Server PROD/VER::4.0,5.0 OPER/SYS: KEYWORDS: ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Internet Information Server versions 4.0, 5.0 ------------------------------------------------------------------------------- SUMMARY ======= This article describes the client authentication process during the Secure Sockets Layer (SSL) handshake. MORE INFORMATION ================ SSL-enabled servers can be configured to require client authentication, or cryptographic validation by the server of the client's identity. When a server that is configured this way requests client authentication, the client sends the server both a certificate and a separate piece of digitally signed data to authenticate itself. The server uses the digitally signed data to validate the public key in the certificate and to authenticate the identity that the certificate claims to represent. The SSL protocol requires the client to create a digital signature by creating a one-way hash from data that is generated randomly during the handshake and that is known only to the client and server. The hash of the data is then encrypted with the private key that corresponds to the public key in the certificate that is being presented to the server. An SSL-enabled server goes through the following steps to authenticate a user's identity: 1. Does the user's public key validate the user's digital signature? The server checks whether the user's digital signature can be validated with the public key in the certificate. If so, the server has established that the public key asserted to belong to the user matches the private key that is used to create the signature and that the data has not been tampered with since it was signed. At this point, however, the binding between the public key and the Distinguished Name (DN) that is specified in the certificate has not yet been established. The certificate might have been created by someone attempting to impersonate the user. To validate the binding between the public key and the DN, the server must also complete step 3 and step 4. 2. Is today's date within the validity period? The server checks the certificate's validity period. If the current date and time are outside of that range, the authentication process does not go any further. If the current date and time are within the certificate's validity period, the server goes on to Step 3. 3. Is the issuing Certificate Authority (CA) a trusted CA? Each SSL-enabled server maintains a list of trusted CA certificates. This list determines which certificates the server will accept. If the DN of the issuing CA matches the DN of a CA on the server's list of trusted CAs, the answer to this question is yes, and the server goes on to Step 4. If the issuing CA is not on the list, the client is not authenticated unless the server can verify a certificate chain ending in a CA that is on the list. Administrators can control which certificates are trusted or not trusted within their organizations by controlling the lists of CA certificates that are maintained by clients and servers. 4. Does the issuing CA's public key validate the issuer's digital signature? The server uses the public key from the CA's certificate (which it found in its list of trusted CAs in step 3) to validate the CA's digital signature on the certificate that is being presented. If the information in the certificate has changed since it was signed by the CA, or if the public key in the CA certificate does not correspond to the private key that was used by the CA to sign the certificate, the server does not authenticate the user's identity. If the CA's digital signature can be validated, the server treats the user's certificate as a valid "letter of introduction" from that CA and proceeds. At this point, the SSL protocol allows the server to consider the client authenticated and proceed with the connection in the next step. 5. Is the authenticated client authorized to access the requested resources? The server checks what resources the client is permitted to access according to the server's access control lists (ACLs) and establishes a connection with appropriate access. If the server does not get to step 5 for any reason, the user that is identified by the certificate cannot be authenticated, and the user is not allowed to access any server resources that require authentication. REFERENCES ========== For additional information, click the article number below to view the article in the Microsoft Knowledge Base: Q257591 Description of the Secure Sockets Layer (SSL) Handshake Additional query words: ====================================================================== Keywords : Technology : kbiisSearch kbiis500 kbiis400 Version : :4.0,5.0 Issue type : kbinfo ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2001.