"oldbear" <oldb***@discussions.microsoft.com> wrote in message
news:0626FCAF-1B3A-4B66-95E7-AB3C848DECB3@microsoft.com...
> Hi
>
> I have a web service which uses WSE for signing, and SSL for
> confidentiality
> and authentication.
>
> Authentication is via client certificates.
>
> The above scenario is already implemented and cannot be changed.
>
> Client certs produced by a Microsoft CA work fine for authentication. The
> certificate is mapped to a user in the SAM via certificate mapping. In the
> IIS log, I can see that the user is the one from the local SAM, and so
> this
> means that the certificate mapping has taken place.
>
> However, when I use a certificate produced by GeoTrust, this will not
> work.
> It results in a 403: Access Forbidden error (status code of 5).
>
> The iis log shows that the mapping to the user account has not taken
> place.
>
> The client cert from the Microsoft CA shows that it is valid for Client
> Authentication only in the properties box, and it's purpose is 'Proves
> your
> identity to a remote computer'.
>
> The certificate from GeoTrust shows that it is valid for Client
> Authentication,  as well as other uses. It's purpose is 'All application
> policies'.
>
> The CRLs for the Geotrust cert have been downloaded from the CRL
> distribution point and placed in the certificate store. Intermediate certs
> have been placed in the Intermediate Authorities folder, and the root
> authority has been placed in the trusted root ca folder.
>
> Please can you give any suggestions on why this does not work. Let me know
> if you need further clarification.
>
> Thanks in advance
>
> --
> ----------------------------------
> Chris Seary
> http://blog.searyblog.com/
>
>

"Joe Kaplan" wrote:

> Do you know which attribute in the certificate is being used to identify the
> user to Windows via the mapping?
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> --
> "oldbear" <oldb***@discussions.microsoft.com> wrote in message
> news:0626FCAF-1B3A-4B66-95E7-AB3C848DECB3@microsoft.com...
> > Hi
> >
> > I have a web service which uses WSE for signing, and SSL for
> > confidentiality
> > and authentication.
> >
> > Authentication is via client certificates.
> >
> > The above scenario is already implemented and cannot be changed.
> >
> > Client certs produced by a Microsoft CA work fine for authentication. The
> > certificate is mapped to a user in the SAM via certificate mapping. In the
> > IIS log, I can see that the user is the one from the local SAM, and so
> > this
> > means that the certificate mapping has taken place.
> >
> > However, when I use a certificate produced by GeoTrust, this will not
> > work.
> > It results in a 403: Access Forbidden error (status code of 5).
> >
> > The iis log shows that the mapping to the user account has not taken
> > place.
> >
> > The client cert from the Microsoft CA shows that it is valid for Client
> > Authentication only in the properties box, and it's purpose is 'Proves
> > your
> > identity to a remote computer'.
> >
> > The certificate from GeoTrust shows that it is valid for Client
> > Authentication,  as well as other uses. It's purpose is 'All application
> > policies'.
> >
> > The CRLs for the Geotrust cert have been downloaded from the CRL
> > distribution point and placed in the certificate store. Intermediate certs
> > have been placed in the Intermediate Authorities folder, and the root
> > authority has been placed in the trusted root ca folder.
> >
> > Please can you give any suggestions on why this does not work. Let me know
> > if you need further clarification.
> >
> > Thanks in advance
> >
> > --
> > ----------------------------------
> > Chris Seary
> > http://blog.searyblog.com/
> >
> >
>
>
>

"oldbear" <oldb***@discussions.microsoft.com> wrote in message
news:D1842445-9DDF-4F02-84B0-5E4EAD753F51@microsoft.com...
> Hi Joe
>
> I used the CN attribute with a wild card. Also tried using a 1 to 1
> mapping
> with an exported .cer file from the cert.
>
> It worked fine with the Microsoft CA cert.
>
>
> --
> ----------------------------------
> Chris Seary
> http://blog.searyblog.com/
>
>
>
>
> "Joe Kaplan" wrote:
>
>> Do you know which attribute in the certificate is being used to identify
>> the
>> user to Windows via the mapping?
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "oldbear" <oldb***@discussions.microsoft.com> wrote in message
>> news:0626FCAF-1B3A-4B66-95E7-AB3C848DECB3@microsoft.com...
>> > Hi
>> >
>> > I have a web service which uses WSE for signing, and SSL for
>> > confidentiality
>> > and authentication.
>> >
>> > Authentication is via client certificates.
>> >
>> > The above scenario is already implemented and cannot be changed.
>> >
>> > Client certs produced by a Microsoft CA work fine for authentication.
>> > The
>> > certificate is mapped to a user in the SAM via certificate mapping. In
>> > the
>> > IIS log, I can see that the user is the one from the local SAM, and so
>> > this
>> > means that the certificate mapping has taken place.
>> >
>> > However, when I use a certificate produced by GeoTrust, this will not
>> > work.
>> > It results in a 403: Access Forbidden error (status code of 5).
>> >
>> > The iis log shows that the mapping to the user account has not taken
>> > place.
>> >
>> > The client cert from the Microsoft CA shows that it is valid for Client
>> > Authentication only in the properties box, and it's purpose is 'Proves
>> > your
>> > identity to a remote computer'.
>> >
>> > The certificate from GeoTrust shows that it is valid for Client
>> > Authentication,  as well as other uses. It's purpose is 'All
>> > application
>> > policies'.
>> >
>> > The CRLs for the Geotrust cert have been downloaded from the CRL
>> > distribution point and placed in the certificate store. Intermediate
>> > certs
>> > have been placed in the Intermediate Authorities folder, and the root
>> > authority has been placed in the trusted root ca folder.
>> >
>> > Please can you give any suggestions on why this does not work. Let me
>> > know
>> > if you need further clarification.
>> >
>> > Thanks in advance
>> >
>> > --
>> > ----------------------------------
>> > Chris Seary
>> > http://blog.searyblog.com/
>> >
>> >
>>
>>
>>

"Joe Kaplan" wrote:

> I might suggest that you post the PEM (base64) version of the certs so we
> could look at them, but I'm not sure you want to do that and I'm not sure
> that would help.  Assuming that the CNs are the same in both certs, there
> must be some other difference that is causing the problem.
>
> Taking a different approach, did you enable Schannel event logging at the
> debug level?  It is often helpful with unraveling various SSL issues.
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> --
> "oldbear" <oldb***@discussions.microsoft.com> wrote in message
> news:D1842445-9DDF-4F02-84B0-5E4EAD753F51@microsoft.com...
> > Hi Joe
> >
> > I used the CN attribute with a wild card. Also tried using a 1 to 1
> > mapping
> > with an exported .cer file from the cert.
> >
> > It worked fine with the Microsoft CA cert.
> >
> >
> > --
> > ----------------------------------
> > Chris Seary
> > http://blog.searyblog.com/
> >
> >
> >
> >
> > "Joe Kaplan" wrote:
> >
> >> Do you know which attribute in the certificate is being used to identify
> >> the
> >> user to Windows via the mapping?
> >>
> >> Joe K.
> >>
> >> --
> >> Joe Kaplan-MS MVP Directory Services Programming
> >> Co-author of "The .NET Developer's Guide to Directory Services
> >> Programming"
> >> http://www.directoryprogramming.net
> >> --
> >> "oldbear" <oldb***@discussions.microsoft.com> wrote in message
> >> news:0626FCAF-1B3A-4B66-95E7-AB3C848DECB3@microsoft.com...
> >> > Hi
> >> >
> >> > I have a web service which uses WSE for signing, and SSL for
> >> > confidentiality
> >> > and authentication.
> >> >
> >> > Authentication is via client certificates.
> >> >
> >> > The above scenario is already implemented and cannot be changed.
> >> >
> >> > Client certs produced by a Microsoft CA work fine for authentication.
> >> > The
> >> > certificate is mapped to a user in the SAM via certificate mapping. In
> >> > the
> >> > IIS log, I can see that the user is the one from the local SAM, and so
> >> > this
> >> > means that the certificate mapping has taken place.
> >> >
> >> > However, when I use a certificate produced by GeoTrust, this will not
> >> > work.
> >> > It results in a 403: Access Forbidden error (status code of 5).
> >> >
> >> > The iis log shows that the mapping to the user account has not taken
> >> > place.
> >> >
> >> > The client cert from the Microsoft CA shows that it is valid for Client
> >> > Authentication only in the properties box, and it's purpose is 'Proves
> >> > your
> >> > identity to a remote computer'.
> >> >
> >> > The certificate from GeoTrust shows that it is valid for Client
> >> > Authentication,  as well as other uses. It's purpose is 'All
> >> > application
> >> > policies'.
> >> >
> >> > The CRLs for the Geotrust cert have been downloaded from the CRL
> >> > distribution point and placed in the certificate store. Intermediate
> >> > certs
> >> > have been placed in the Intermediate Authorities folder, and the root
> >> > authority has been placed in the trusted root ca folder.
> >> >
> >> > Please can you give any suggestions on why this does not work. Let me
> >> > know
> >> > if you need further clarification.
> >> >
> >> > Thanks in advance
> >> >
> >> > --
> >> > ----------------------------------
> >> > Chris Seary
> >> > http://blog.searyblog.com/
> >> >
> >> >
> >>
> >>
> >>
>
>
>

"oldbear" <oldb***@discussions.microsoft.com> wrote in message
news:C8E5B996-4819-47DB-8C34-8255F1E1B100@microsoft.com...
> Hi Joe
>
> Thanks very much for your help with this.
>
> We've had another look at the different stores in the certs applet, and
> found an item was missing from trusted roots for local machine. This was
> an
> oversight, and so it now works fine. Doh!
>
> Sorry for wasting your time due to carelessness, but it's been a very long
> day  :-)
>
> Cheers
>
>
> --
> ----------------------------------
> Chris Seary
> http://blog.searyblog.com/
>
>
>
>
> "Joe Kaplan" wrote:
>
>> I might suggest that you post the PEM (base64) version of the certs so we
>> could look at them, but I'm not sure you want to do that and I'm not sure
>> that would help.  Assuming that the CNs are the same in both certs, there
>> must be some other difference that is causing the problem.
>>
>> Taking a different approach, did you enable Schannel event logging at the
>> debug level?  It is often helpful with unraveling various SSL issues.
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "oldbear" <oldb***@discussions.microsoft.com> wrote in message
>> news:D1842445-9DDF-4F02-84B0-5E4EAD753F51@microsoft.com...
>> > Hi Joe
>> >
>> > I used the CN attribute with a wild card. Also tried using a 1 to 1
>> > mapping
>> > with an exported .cer file from the cert.
>> >
>> > It worked fine with the Microsoft CA cert.
>> >
>> >
>> > --
>> > ----------------------------------
>> > Chris Seary
>> > http://blog.searyblog.com/
>> >
>> >
>> >
>> >
>> > "Joe Kaplan" wrote:
>> >
>> >> Do you know which attribute in the certificate is being used to
>> >> identify
>> >> the
>> >> user to Windows via the mapping?
>> >>
>> >> Joe K.
>> >>
>> >> --
>> >> Joe Kaplan-MS MVP Directory Services Programming
>> >> Co-author of "The .NET Developer's Guide to Directory Services
>> >> Programming"
>> >> http://www.directoryprogramming.net
>> >> --
>> >> "oldbear" <oldb***@discussions.microsoft.com> wrote in message
>> >> news:0626FCAF-1B3A-4B66-95E7-AB3C848DECB3@microsoft.com...
>> >> > Hi
>> >> >
>> >> > I have a web service which uses WSE for signing, and SSL for
>> >> > confidentiality
>> >> > and authentication.
>> >> >
>> >> > Authentication is via client certificates.
>> >> >
>> >> > The above scenario is already implemented and cannot be changed.
>> >> >
>> >> > Client certs produced by a Microsoft CA work fine for
>> >> > authentication.
>> >> > The
>> >> > certificate is mapped to a user in the SAM via certificate mapping.
>> >> > In
>> >> > the
>> >> > IIS log, I can see that the user is the one from the local SAM, and
>> >> > so
>> >> > this
>> >> > means that the certificate mapping has taken place.
>> >> >
>> >> > However, when I use a certificate produced by GeoTrust, this will
>> >> > not
>> >> > work.
>> >> > It results in a 403: Access Forbidden error (status code of 5).
>> >> >
>> >> > The iis log shows that the mapping to the user account has not taken
>> >> > place.
>> >> >
>> >> > The client cert from the Microsoft CA shows that it is valid for
>> >> > Client
>> >> > Authentication only in the properties box, and it's purpose is
>> >> > 'Proves
>> >> > your
>> >> > identity to a remote computer'.
>> >> >
>> >> > The certificate from GeoTrust shows that it is valid for Client
>> >> > Authentication,  as well as other uses. It's purpose is 'All
>> >> > application
>> >> > policies'.
>> >> >
>> >> > The CRLs for the Geotrust cert have been downloaded from the CRL
>> >> > distribution point and placed in the certificate store. Intermediate
>> >> > certs
>> >> > have been placed in the Intermediate Authorities folder, and the
>> >> > root
>> >> > authority has been placed in the trusted root ca folder.
>> >> >
>> >> > Please can you give any suggestions on why this does not work. Let
>> >> > me
>> >> > know
>> >> > if you need further clarification.
>> >> >
>> >> > Thanks in advance
>> >> >
>> >> > --
>> >> > ----------------------------------
>> >> > Chris Seary
>> >> > http://blog.searyblog.com/
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>