Vavada - это онлайн-казино, предоставляющее широкий выбор азартных игр, включая слоты, рулетку, блэкджек и другие. Vavada привлекает игроков разнообразными бонусами и акциями.

In part 1 of this feature, we discussed the process for obtaining and installing a server certificate for SSL enablement in IIS 6.0. This will provide confidentiality to HTTP sessions created between the server and its clients. To enable authentication of the users, however, you must enable mutual authentication. This will require the users of the system to have obtained digital signature credentials, or they will not be able to access the system!

  • Start the Internet Services Manager by selecting Start -> Administrative Tools -> Internet Services Manager. (Note: in various versions of Windows, this shortcut may contain a slightly different path in the Start menu.)
  • Right-click the web site node in the IIS manager, and open the Properties dialog.
  • Select the Directory Security tab
  • In the Secure Communications section, click the Edit… button
  • In the Client Certificates section, select the radio button labeled Require client certificates

At this point, any client certificate that can be validated against a self-signed issuer certificate in the CAPI machine store can be used to access the web site. A copy of this certificate will be available to any server-side application, such as within ASP.NET code. If you want to restrict the allowed clients to those issued by a subset of the trust roots installed in CAPI, perform the following steps. Otherwise, Click OK to exit the configuration screen.

  • Check the box labeled Enable Certificate Trust List
  • Click the New… button under the Certificate Trust List drop-down list
  • Complete the wizard by taking the following actions:
    • Click Next on the Welcome screen
    • Click Add from Store if the trusted issuer certificate is installed in the CAPI store. Otherwise, click Add from File
    • Select the trusted certificate, and click OK (or Open)
    • When all of the trusted issuers are present in the list, click Next
    • Enter a friendly name and description, and click Next
    • Review the summary, and click Finish
  • Make sure the trust list you just created is selected in the Current CTL drop-down list, and click OK
  • Click OK to exit the wizard

If set up correctly, the web site will now require you to present a digital signature certificate issued by a trusted authority when accessing the web site. During the SSL negotiation, the server will send a list of trusted issuers to the client browser. In many browsers, if only one usable credential is present, the negotiation may be completed automatically without prompting the user. If there are multiple available credentials, the user will be prompted to select one. Keep this in mind while testing – if the browser does not prompt you to select a certificate, it may indicate that you only have one certificate to use and the browser is selecting the certificate for you, not that the configuration is incorrect!

2 thoughts on “Client SSL Authentication for Microsoft IIS Part 2: Setting up Mutual Authentication

  1. Beat Kiener says:

    Very help full article. Now it almost works for me, with one problem: how do I set which are the trusted publishers? I have two client certificates from two different issuers on two different smartcards. The browser only asks for the certificate when I use the smartcard from issuer A, with B it does not show the dialog. How can I tell IIS that it should send issuer B as trusted publisher to the browser in order that the browser will send the certificate from smartcard B?

  2. Walt says:

    If all of the trusted issuers are present in the trust list set up in the second set of bullet points, the next things to check are:

    a) can the client build a trusted certificate chain back to the root certificate? If not, the browser may not see the certificate as valid

    and

    b) are the client certificates revoked, expired, etc? If the client certificates are invalid, the browser might also disallow them from being used.

    Also, since you are using smart cards, you should make sure that when you plug the smart card in, the certificate is being registered in the CAPI store – if the underlying CAPI subsystem doesn’t know that the smart card is plugged in, then it won’t be aware of the certificate.

Comments are closed.