[isapros] Re: SSL Client Certificate Authentication with non-web clients
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 24 Aug 2007 08:22:27 -0700
I mean "certificate bridging" cannot work.
There is no way for ISA to "proxy" the certificate that was presented by the
user to the upstream server..
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thor (Hammer of God)
Sent: Friday, August 24, 2007 6:56 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: SSL Client Certificate Authentication with non-web
clients
In this case, the "owner" need but supply a certificate signed by a CA that ISA
trusts and is configured to allow for that listener. Even if I install the
exact same user cert on ISA, *with* the private key, we get the error.
But when you say "it can't work" you mean something else, right?
t
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Friday, August 24, 2007 6:48 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> They're both "SSL certs"; the one presented by the server (ISA or the
> upstream server) contains a "purpose" of at least "Server
> Authentication", while the one presented by the user contains a
> "purpose" of at least "Client Authentication" (they can both hold many
> more or only "All purposes").
>
> The reason it can't work is because in order to present a certificate,
> the "owner" has to have the private key for that certificate; ISA
> doesn't have this for the user cert and can't get it.
>
> http://www.microsoft.com/technet/security/guidance/cryptographyetc/cryp
> tpki.mspx offers a basic explanation of this process.
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> Sent: Friday, August 24, 2007 6:29 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> That sounds a bit different than how it works with SSL bridging. Good
> to know, though. I would have thought you could have done bridging
> with a user cert, too, just like an SSL cert - meaning the ISA server
> decrypts, inspects, encrypts again, and passes on to the upstream
> server.
>
> Thanks again, JJBA. ;)
>
> Cordially yours,
> Jerry G. Young II
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Application Engineer
> Platform Engineering & Architecture
> NTT America, an NTT Communications Company
> =====================================
> 22451 Shaw Rd.
> Sterling, VA 20166
> Office: 571-434-1319
> Fax: 703-333-6749
> Email: g.young@xxxxxxxx
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> "The truth is that there is nothing noble in being superior to somebody
> else.
> The only real nobility is in being superior to your former self."
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Friday, August 24, 2007 9:20 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> Actually, you don't "need" a certificate at the upstream server unless
> you want to maintain SSL encryption along all paths.
> Certificates (regardless of type) cannot be bridged.
> If you want user cert auth at the ISA web listener you cannot have it
> at the upstream server.
> If you want user cert auth at the upstream server, you *must* use
> tunneling (Server publishing) to allow the SSL handshake (where
> certificates are exchanged) to proceed between the client and server
> unimpeded.
>
> Tim & I are still playing with his stuff; interesting problems; yup-
> yup.
>
> JimmyJoeBobAlooba
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> Sent: Friday, August 24, 2007 6:15 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> Here was a final thought I had yesterday but didn't have time to
> respond.
>
> We've been talking primarily about the listener and its configuration
> on the ISA server. Wouldn't there be a published server component,
> too, though, like there is with an SSL cert - need to install SSL cert
> on published server, copy it, and install it onto the ISA server to tie
> to a listener?
>
> Might the same be required for client cert use against the published
> server?
>
> Cordially yours,
> Jerry G. Young II
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Application Engineer
> Platform Engineering & Architecture
> NTT America, an NTT Communications Company
> =====================================
> 22451 Shaw Rd.
> Sterling, VA 20166
> Office: 571-434-1319
> Fax: 703-333-6749
> Email: g.young@xxxxxxxx
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> "The truth is that there is nothing noble in being superior to somebody
> else.
> The only real nobility is in being superior to your former self."
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Thursday, August 23, 2007 9:25 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> Me & Tim bees playin'...
> We'll respond when we've sorted it all out.
>
> JimmyJoeBobAlooba
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Thursday, August 23, 2007 4:41 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> CIL...
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> Sent: Thursday, August 23, 2007 3:48 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> You mean "force authentication" at the rule, not the listener, right?
> [Jim] - sorta, but there is no such setting at the rule. You
> accomplish this by include only "Authenticated Users in the "Users"
> tab.
>
> Doesn't matter anyway- same thing. I go to the site, present my
> "client certificate" which it accepts apparently, then I get:
> Error Code: 401 Unauthorized. The server requires authorization to
> fulfill the request. Access to the Web server is denied. Contact the
> server administrator. (12209)
> [Jim] - 12209 is an authentication failure (yeh; I know - "DUH!").
> Oddly enough, this is also seen when you would actually expect a
> 403/12202. What is:
> - the "public name" allowed for the rule?
> - the path(s) specified in the rule?
> - the *exact* URL you're using in the test browser?
>
> Nothing in the logs at all, either on the ISA box or the back end web
> server. Nor is there anything in the web logs of the back end server.
>
> As I said before, if I change the CA to something other than my domain
> CA, when I present my domain client cert, it fails saying I need a
> different cert.
> t
>
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > Sent: Thursday, August 23, 2007 3:43 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: SSL Client Certificate Authentication with
> non-
> > web clients
> >
> > That's why you need "force authentication" at the listener.
> > Change it to "all authenticated" and you should see different
> behavior.
> > If you still get failures, check the security event log for SChannel
> > errors.
> > ISA and IIS both use SChannel to validate user certs by requesting a
> > Kerberos ticket for that user account. Errors in this process will
> be
> > reflected in the Security event log.
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > Sent: Thursday, August 23, 2007 3:40 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: SSL Client Certificate Authentication with
> non-
> > web clients
> >
> > All users...
> >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > Sent: Thursday, August 23, 2007 3:36 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > > Is your rule set for "all users" or "all authenticated users".
> > > Might be simpler to just send me your ISAInfo or BPA repro...
> > >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > Sent: Thursday, August 23, 2007 3:09 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > > I hoping you'd help out with this....
> > >
> > > I'm not combining it with any other method.
> > >
> > > Under "Client Authentication Method" I select "SSL Client
> Certificate
> > > Authentication" and specify the CA that must have signed the client
> > > certs.
> > > It doesn't work.
> > >
> > > What else am i supposed to do?
> > >
> > > t
> > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > > Sent: Thursday, August 23, 2007 2:54 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > > non-
> > > > web clients
> > > >
> > > > You can combine FBA & client cert, but only if you select client
> > cert
> > > > from the FBA configuration.
> > > > You cannot combine "primary" user cert auth (selected from the
> > > listener
> > > > auth schemes UI) and any other auth method.
> > > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > > Sent: Thursday, August 23, 2007 2:12 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > > non-
> > > > web clients
> > > >
> > > > If I leave "require client cert" but remove "require
> > authentication"
> > > > then any client can connect from anywhere without regard to
> > > > certificates.
> > > >
> > > > I absolutely agree that the expected behavior would be that
> without
> > a
> > > > client cert, that you could not connect. But you can.
> > > >
> > > >
> > > >
> > > > In fact, from a client with or without a client cert, when
> "require
> > > > authentication" is removed, the listener does not even ask for a
> > > client
> > > > certificate-- it just goes right to the web site.
> > > >
> > > >
> > > >
> > > > It is "poo poo"
> > > >
> > > >
> > > >
> > > > t
> > > >
> > > >
> > > >
> > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > > Sent: Thursday, August 23, 2007 2:07 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > > non-
> > > > web clients
> > > >
> > > >
> > > >
> > > > No, I meant what if you leave " require client cert", remove
> > "require
> > > > authentication", and then...
> > > >
> > > > Test 1
> > > > From a client without a client cert installed try to connect.
> Can
> > > you?
> > > > Expected result is no, you can't.
> > > >
> > > > Test 2
> > > > From a client with a client cert installed try to connect. Can
> > you?
> > > > Expected result is yes, you can.
> > > >
> > > > Cordially yours,
> > > > Jerry G. Young II ++ Sent from BlackBerry ++
> > > > Application Engineer
> > > > Platform Engineering and Architecture
> > > > NTT America, an NTT Communications Company
> > > >
> > > > 22451 Shaw Rd.
> > > > Sterling, VA 20166
> > > >
> > > > Office: 571-434-1319
> > > > Fax: 703-333-6749
> > > > Email: g.young@xxxxxxxx
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx <isapros-bounce@xxxxxxxxxxxxx>
> > > > To: isapros@xxxxxxxxxxxxx <isapros@xxxxxxxxxxxxx>
> > > > Sent: Thu Aug 23 16:52:46 2007
> > > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > > non-
> > > > web clients
> > > >
> > > > If I select "require authentication," but don't have a client
> cert,
> > I
> > > > cannot present the cert (have an empty "select cert" window) and
> > > can't
> > > > access the site.
> > > > If I load the cert properly, it is available to present, but
> after
> > I
> > > > present it, I get the 401 authentication error.
> > > > If I tell ISA to use a *different* CA (one that I don't have),
> but
> > > > present my domain cert, it comes back and tells me to select a
> > > > different certificate.
> > > >
> > > > The client I'm testing from is not on the domain, and I'm not
> > logged
> > > on
> > > > as a domain user for ISA-- but I shouldn't be. I'm testing what
> > > would
> > > > be a "standard"' internet user accessing an SSL site that is
> > > configured
> > > > to require a client-side cert for access.
> > > >
> > > > The goal is to limit who can connect up to the site in the first
> > > place
> > > > via user cert, just like what you can do in IIS directly with
> > client
> > > > cert mapping. I'm hoping that I don't also have to go to the IIS
> > > site
> > > > and configure some sort of client cert mapping voodoo-- if you
> have
> > > to
> > > > do that, there is no use in having the listener require a client
> > > cert.
> > > >
> > > > Still macking at it ;)
> > > >
> > > > t
> > > >
> > > > > -----Original Message-----
> > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > > > Sent: Thursday, August 23, 2007 1:46 PM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> with
> > > > non-
> > > > > web clients
> > > > >
> > > > > Can you connect from a client that doesn't have a client cert
> > > > > installed?
> > > > >
> > > > > For the "Require SLL Certificate" checkbox being grayed out,
> can
> > > you
> > > > > have both a SLL Cert for the server AND require a client cert?
> > > Isn't
> > > > > that a one-or-the-other kind of thing?
> > > > >
> > > > > Yeah, I'm sorry I'm not able to help more. :(
> > > > >
> > > > > Are you on your client as an AD user from the domain in which
> the
> > > ISA
> > > > > server exists?
> > > > >
> > > > > Have you taken a network trace to see what kind of
> communication
> > is
> > > > > occurring between the ISA server and the client?
> > > > >
> > > > > I'm grasping here but... :)
> > > > >
> > > > > Cordially yours,
> > > > > Jerry G. Young II
> > > > >
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > Application Engineer
> > > > > Platform Engineering & Architecture
> > > > > NTT America, an NTT Communications Company
> > > > > =====================================
> > > > > 22451 Shaw Rd.
> > > > > Sterling, VA 20166
> > > > > Office: 571-434-1319
> > > > > Fax: 703-333-6749
> > > > > Email: g.young@xxxxxxxx
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > "The truth is that there is nothing noble in being superior to
> > > > somebody
> > > > > else.
> > > > > The only real nobility is in being superior to your former
> self."
> > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > > > Sent: Thursday, August 23, 2007 4:39 PM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> with
> > > > non-
> > > > > web clients
> > > > >
> > > > > I agree completely- "require authentication" seems like, in
> > > addition
> > > > to
> > > > > the client cert, that the client must be authenticated via "one
> > of
> > > > the
> > > > > selected methods," in this case AD (the only radial button
> > > selected-
> > > > > and it is grayed out).
> > > > >
> > > > > What is curious the that the "Require SSL Certificate" is
> grayed
> > > out
> > > > > and unchecked. But why would that option be there in the first
> > > place
> > > > > if I've explicitly said I'm requiring a client cert? The help
> is
> > > > > useless in this regard, and I'm not finding much other info on
> > > it...
> > > > >
> > > > > But thanks for your input ;)
> > > > > t
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > > > > Sent: Thursday, August 23, 2007 1:34 PM
> > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> > with
> > > > > non-
> > > > > > web clients
> > > > > >
> > > > > > No other thoughts than I always assumed a 401 error was for
> > > failure
> > > > > of
> > > > > > user authentication, not client cert authentication. I would
> > > have
> > > > > > assumed that by configuring a listener to use client certs, a
> > > > browser
> > > > > > wouldn't even be able to connect without one (don't remember
> > > > > selecting
> > > > > > a cert to present). I thought requiring a client cert and
> > > > requiring
> > > > > > authentication were two different things. If the issue
> really
> > is
> > > > > > something simple and not a... ahem... bug, my money would be
> on
> > > the
> > > > > > understanding of the difference of those two settings.
> > > > > >
> > > > > > Cordially yours,
> > > > > > Jerry G. Young II
> > > > > >
> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > Application Engineer
> > > > > > Platform Engineering & Architecture
> > > > > > NTT America, an NTT Communications Company
> > > > > > =====================================
> > > > > > 22451 Shaw Rd.
> > > > > > Sterling, VA 20166
> > > > > > Office: 571-434-1319
> > > > > > Fax: 703-333-6749
> > > > > > Email: g.young@xxxxxxxx
> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >
> > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > > "The truth is that there is nothing noble in being superior
> to
> > > > > somebody
> > > > > > else.
> > > > > > The only real nobility is in being superior to your former
> > self."
> > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > > > > Sent: Thursday, August 23, 2007 4:23 PM
> > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> > with
> > > > > non-
> > > > > > web clients
> > > > > >
> > > > > > I'm hitting the listener as an anonymous user, yes. But, I'm
> > > > > providing
> > > > > > the cert as authentication. If I don't "require
> > authentication"
> > > in
> > > > > the
> > > > > > "SSL Client Certificate Authentication" properties, it never
> > asks
> > > > the
> > > > > > client to provide a cert. And just to ensure that the
> browser
> > > > isn't
> > > > > > "automatically" sending anything, I've deleted the client
> cert
> > > and
> > > > > > removed the domain CA cert from root certs on the client box
> --
> > > > with
> > > > > > "require authentication" cleared, but requiring SSL Client
> Cert
> > > > Auth,
> > > > > > the client, the client can still connect to the server
> without
> > > > > > presenting a certificate (which doesn't make any since to me)
> > and
> > > > > there
> > > > > > is no fallback auth specified.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > t
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > > > > > Sent: Thursday, August 23, 2007 1:15 PM
> > > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > > Subject: [isapros] Re: SSL Client Certificate
> Authentication
> > > with
> > > > > > non-
> > > > > > > web clients
> > > > > > >
> > > > > > > Are you still logging on as an anonymous user? Since
> you're
> > > > > > > configuring the listener to use a client cert and require
> > > > > > > authentication, shouldn't you be authenticating against the
> > ISA
> > > > > > server?
> > > > > > >
> > > > > > > Cordially yours,
> > > > > > > Jerry G. Young II
> > > > > > >
> > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > Application Engineer
> > > > > > > Platform Engineering & Architecture
> > > > > > > NTT America, an NTT Communications Company
> > > > > > > =====================================
> > > > > > > 22451 Shaw Rd.
> > > > > > > Sterling, VA 20166
> > > > > > > Office: 571-434-1319
> > > > > > > Fax: 703-333-6749
> > > > > > > Email: g.young@xxxxxxxx
> > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > >
> > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > > > "The truth is that there is nothing noble in being superior
> > to
> > > > > > somebody
> > > > > > > else.
> > > > > > > The only real nobility is in being superior to your former
> > > self."
> > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > > > > > Sent: Thursday, August 23, 2007 4:10 PM
> > > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > > Subject: [isapros] Re: SSL Client Certificate
> Authentication
> > > with
> > > > > > non-
> > > > > > > web clients
> > > > > > >
> > > > > > > OK... Help me out with this one-- forget about RDP, etc.
> I'm
> > > > just
> > > > > > > trying to get an SLL Listener to require an SSL Client
> > > > Certificate
> > > > > > for
> > > > > > > authentication, and am having some issues- i'm sure it's
> > > > something
> > > > > > > easy,
> > > > > > > but I'm missing it.
> > > > > > >
> > > > > > > Start from the basics without requiring auth on the
> listener:
> > > > > > > 1) Create SSL listener with proper cert
> > > > > > > 2) publish to internal site
> > > > > > > 3) got to https://www.domain.com and it works fine (either
> > > > bridged
> > > > > to
> > > > > > > 443 or redirected to 80) as anonymous user.
> > > > > > > 4) at this point, everything works just fine...
> > > > > > >
> > > > > > > Now, I tell the listener to require a client-side cert for
> > > > > > > authentication- in this case, it is a cert that must be
> > signed
> > > by
> > > > > my
> > > > > > > own
> > > > > > > domain CA. The ISA box is NOT on that domain.
> > > > > > > 1) install CA cert in trusted root certificates on ISA box.
> > It
> > > > > > works,
> > > > > > > and is valid.
> > > > > > > 2) install User cert created by the CA on client box with
> > path
> > > to
> > > > > > root
> > > > > > > cert. Move CA cert to trusted root certs. User cert is
> > valid,
> > > > > cert
> > > > > > > path is valid.
> > > > > > > 3) Configure listener to use client cert, and to require
> > > > > > > authentication.
> > > > > > > If I don't require, the client does not have to present a
> > cert.
> > > > I
> > > > > > > further tell ISA to only accept certs trusted by the domain
> > CA
> > > > (it
> > > > > > > shows
> > > > > > > up in the list, of course). Note that behavior does not
> > change
> > > > if
> > > > > I
> > > > > > > select "all CA's"
> > > > > > > 4) Configure the system policy on ISA for CRL lookups
> > > > > > > 5) Verify the ISA box can get to the CRL path specified in
> > the
> > > > cert
> > > > > > > 6) from the client, go to https://www.domain.com and it
> asks
> > > for
> > > > a
> > > > > > > cert.
> > > > > > > The cert is available, and i present it: but I always get:
> > > > > > >
> > > > > > > Error Code: 401 Unauthorized. The server requires
> > authorization
> > > > to
> > > > > > > fulfill the request. Access to the Web server is denied.
> > > Contact
> > > > > the
> > > > > > > server administrator. (12209)
> > > > > > >
> > > > > > > Removing the SCCA returns things to normal. I've even
> tried
> > > > > > publishing
> > > > > > > to different back end servers... same thing.
> > > > > > >
> > > > > > > What could be the problem?
> > > > > > > t
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > > > > > > Sent: Thursday, August 23, 2007 11:26 AM
> > > > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > > > Subject: [isapros] Re: SSL Client Certificate
> > Authentication
> > > > with
> > > > > > > non-
> > > > > > > > web clients
> > > > > > > >
> > > > > > > > The point of using a browser on not is not relevant.
> > > > > > > > It's the client application's responsibility to handle
> the
> > > > return
> > > > > > > from
> > > > > > > > SCHannel that says "pick a cert of type 'X'".
> Supposedly,
> > > the
> > > > v6
> > > > > > RDP
> > > > > > > > client knows how to prompt for smartcard certs, but I
> > haven't
> > > > > > > > personally
> > > > > > > > tested this. Word on the streets is that "soft-certs"
> > should
> > > > > also
> > > > > > > > work,
> > > > > > > > but again; I haven't personally tested this.
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > > > bounce@xxxxxxxxxxxxx]
> > > > > > > > On Behalf Of Thor (Hammer of God)
> > > > > > > > Sent: Thursday, August 23, 2007 7:26 AM
> > > > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > > > Subject: [isapros] SSL Client Certificate Authentication
> > with
> > > > > non-
> > > > > > web
> > > > > > > > clients
> > > > > > > >
> > > > > > > > So, in an earlier thread, we discussed using certificates
> > to
> > > > > > control
> > > > > > > > what clients could connect to a published RDP server. As
> > we
> > > > saw,
> > > > > > > this
> > > > > > > > is not possible in Vista/2003 implementations. However,
> we
> > > see
> > > > > > that
> > > > > > > in
> > > > > > > > TSGateway, one uses an SSL listener (with public names to
> > > /rpc)
> > > > > to
> > > > > > > > publish access to TSGateway functionality via RDP over
> > > > RPC/HTTP.
> > > > > > The
> > > > > > > > TSGateway configuration allows you to specify smart-card
> > > logon,
> > > > > but
> > > > > > > in
> > > > > > > > the absence of that, the recommendation was made to use
> > "SSL
> > > > > Client
> > > > > > > > Certificate Authentication" restrictions at the SSL
> > listener
> > > > > > itself.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > However, I don't see how this will work. As I see it,
> the
> > > only
> > > > > way
> > > > > > > to
> > > > > > > > use SCCA on a web listener is for the client to be a
> > browser
> > > -
> > > > > > that's
> > > > > > > > how the user is given the option of choosing which cert
> to
> > > > > present
> > > > > > to
> > > > > > > > the server. In the case of an RDP client (MSTSC.exe)
> > > > connecting
> > > > > to
> > > > > > a
> > > > > > > > TSGateway published via an SCCA web listener, it won't
> work
> > > as
> > > > > > there
> > > > > > > is
> > > > > > > > no way to present a cert.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > So, we really can't use SCCA as it relates to RDP,
> correct?
> > > Or
> > > > > is
> > > > > > > > there
> > > > > > > > some secret squirrel configuration I don't know about?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > t
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -----------------------------
> > > > > > > >
> > > > > > > > vinni, viddi, vinni denuo
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > All mail to and from this domain is GFI-scanned.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > =================================
> > > > > > >
> > > > > > > This email message is intended for the use of the person to
> > > whom
> > > > it
> > > > > > has
> > > > > > > been sent, and may contain information that is confidential
> > or
> > > > > > legally
> > > > > > > protected. If you are not the intended recipient or have
> > > received
> > > > > > this
> > > > > > > message in error, you are not authorized to copy,
> distribute,
> > > or
> > > > > > > otherwise use this message or its attachments. Please
> notify
> > > the
> > > > > > sender
> > > > > > > immediately by return e-mail and permanently delete this
> > > message
> > > > > and
> > > > > > > any attachments. NTT America makes no warranty that this
> > email
> > > is
> > > > > > error
> > > > > > > or virus free. Thank you.
> > > > > >
> > > > > >
> > > > > >
> > > > > > =================================
> > > > > >
> > > > > > This email message is intended for the use of the person to
> > whom
> > > it
> > > > > has
> > > > > > been sent, and may contain information that is confidential
> or
> > > > > legally
> > > > > > protected. If you are not the intended recipient or have
> > received
> > > > > this
> > > > > > message in error, you are not authorized to copy, distribute,
> > or
> > > > > > otherwise use this message or its attachments. Please notify
> > the
> > > > > sender
> > > > > > immediately by return e-mail and permanently delete this
> > message
> > > > and
> > > > > > any attachments. NTT America makes no warranty that this
> email
> > is
> > > > > error
> > > > > > or virus free. Thank you.
> > > > >
> > > > >
> > > > >
> > > > > =================================
> > > > >
> > > > > This email message is intended for the use of the person to
> whom
> > it
> > > > has
> > > > > been sent, and may contain information that is confidential or
> > > > legally
> > > > > protected. If you are not the intended recipient or have
> received
> > > > this
> > > > > message in error, you are not authorized to copy, distribute,
> or
> > > > > otherwise use this message or its attachments. Please notify
> the
> > > > sender
> > > > > immediately by return e-mail and permanently delete this
> message
> > > and
> > > > > any attachments. NTT America makes no warranty that this email
> is
> > > > error
> > > > > or virus free. Thank you.
> > > >
> > > >
> > > >
> > > > =================================
> > > >
> > > > This email message is intended for the use of the person to whom
> it
> > > has
> > > > been sent, and may contain information that is confidential or
> > > legally
> > > > protected. If you are not the intended recipient or have received
> > > this
> > > > message in error, you are not authorized to copy, distribute, or
> > > > otherwise use this message or its attachments. Please notify the
> > > sender
> > > > immediately by return e-mail and permanently delete this message
> > and
> > > > any attachments. NTT America makes no warranty that this email is
> > > error
> > > > or virus free. Thank you.
> > > >
> > > >
> > > >
> > > >
> > > > All mail to and from this domain is GFI-scanned.
> > > >
> > >
> > >
> > > All mail to and from this domain is GFI-scanned.
> > >
> >
> >
> > All mail to and from this domain is GFI-scanned.
> >
>
>
> All mail to and from this domain is GFI-scanned.
>
>
>
> All mail to and from this domain is GFI-scanned.
>
>
>
>
> =================================
>
> This email message is intended for the use of the person to whom it has
> been sent, and may contain information that is confidential or legally
> protected. If you are not the intended recipient or have received this
> message in error, you are not authorized to copy, distribute, or
> otherwise use this message or its attachments. Please notify the sender
> immediately by return e-mail and permanently delete this message and
> any attachments. NTT America makes no warranty that this email is error
> or virus free. Thank you.
>
>
> All mail to and from this domain is GFI-scanned.
>
>
>
>
> =================================
>
> This email message is intended for the use of the person to whom it has
> been sent, and may contain information that is confidential or legally
> protected. If you are not the intended recipient or have received this
> message in error, you are not authorized to copy, distribute, or
> otherwise use this message or its attachments. Please notify the sender
> immediately by return e-mail and permanently delete this message and
> any attachments. NTT America makes no warranty that this email is error
> or virus free. Thank you.
>
>
> All mail to and from this domain is GFI-scanned.
>
All mail to and from this domain is GFI-scanned.
Other related posts:
