How to make IIS 6.0 to accept client certificates issued by any CA
in [IIS]
|
Prev: How to secure common directories in iis7.0
Next: different system message when viewing iis7 internally and external
From: Santiago Arechaga on 12 Mar 2010 08:59 I've been doing some research about this, on how to configure IIS 6.0 to accept client certificates issued by any CA (including certificates issued by CAs not trusted by IIS or the server), and it seems it's not possible in IIS 6.0. Is this right? I can not make IIS to accept any certificate the client wants to send? I've read that other web servers, like Apache, can be configured to accept all client certificates, whatever the issuing CA will be. The reason for this is that we're using a third-party certificate validation service, as the list of accepted CAs changes too often, and we don't want to have to maintain that list on the server. Moreover, the server has no internet access (per security reasons) and we have already disable the revocation check by setting the "CheckCertMode" property in the Metabase to "1". 1. The application does not need to map certificates to Windows accounts. The Web application executes using the Pool credentials (with the anonymous authentication). 2. The validation of the certificate is performed by a third-party service, which has all the accepted CAs and does all the validations, including expiration, revocation, cet-chain validation, etc. 3. Thus, forged or self-signed certificates will be rejected by the validation service, as the issuing CA will not be on the validation root CA list or the signature of the cert will not match a signature created by the real CA if it's a forged cert. Hope this clarifies why I need to accept ANY client certificate. -- Thanks in advance, Santiago
From: Ken Schaefer on 14 Mar 2010 01:44
Hasn't this been asked/answered previously? Using client certs sets up a SSL/TLS session and the way that works is by IIS sending a list of accepted CAs to the client (I don't believe you can change this behavior), and the browser then shows the user a list of acceptable certs (I don't know how you are going to change this is the client!) and the user selects one. You could write your own ISAPI filter to change IIS behavior, but I don't know how you are going to change the client behavior if it's a browser. Cheers Ken http://adOpenStatic.com/blog "Santiago Arechaga" <sarechaga(a)nospam.nospam> wrote in message news:C2C3B911-4C3A-4292-945A-3567CCA77AE1(a)microsoft.com... > I've been doing some research about this, on how to configure IIS 6.0 to > accept client certificates issued by any CA (including certificates issued > by > CAs not trusted by IIS or the server), and it seems it's not possible in > IIS > 6.0. > > Is this right? I can not make IIS to accept any certificate the client > wants > to send? > I've read that other web servers, like Apache, can be configured to accept > all client certificates, whatever the issuing CA will be. > > The reason for this is that we're using a third-party certificate > validation > service, as the list of accepted CAs changes too often, and we don't want > to > have to maintain that list on the server. Moreover, the server has no > internet access (per security reasons) and we have already disable the > revocation check by setting the "CheckCertMode" property in the Metabase > to > "1". > > 1. The application does not need to map certificates to Windows accounts. > The Web application executes using the Pool credentials (with the > anonymous > authentication). > 2. The validation of the certificate is performed by a third-party > service, > which has all the accepted CAs and does all the validations, including > expiration, revocation, cet-chain validation, etc. > 3. Thus, forged or self-signed certificates will be rejected by the > validation service, as the issuing CA will not be on the validation root > CA > list or the signature of the cert will not match a signature created by > the > real CA if it's a forged cert. > > Hope this clarifies why I need to accept ANY client certificate. > > -- > Thanks in advance, > Santiago > |