[isapros] Re: SSL Client Certificate Authentication with non-web clients
- From: "Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 24 Aug 2007 15:11:48 -0700
And besides, one of my most respected friends in the industry uses the
term "client certificates" in article's he written about this very
subject - so if you don't mind me saying so, I will take his use of it
as gospel:
"Client certificate authentication allows users to present client
certificates to authenticate with the Incoming Web Requests listener"
and
"For example, you can publish the Web enrollment site and allow external
network clients to obtain a client certificate from the Internet..."
and finally,
"Check out chapter 5 of the ISA Server and Beyond book for details on
using client certificates on the ISA Server"
I'll leave it up to you to figure out the author of those quotes. :-p
t
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> Sent: Friday, August 24, 2007 12:46 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> You're getting closer to precision. But until you use the term "user
> certificate" you fall far from the mark of good nosology and
> nomenclature and fit into the mold of the uneducated "IT guy".
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx]
> On Behalf Of Thor (Hammer of God)
> Sent: Friday, August 24, 2007 2:13 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with
> non-web clients
>
> The client is defined by the context in which an operation is
> performed.
> If it is a logged-on account presenting a certificate whose role is
> "Client Authentication" then the "client" is a "user." If it is a
> service presenting a certificate whose role is "Client Authentication"
> then the "client" is a "service."
>
> Describing the certificate as a "Client Certificate" defines the role
> of
> the certificate outside of the context presenting it. In that regard,
> "user certificate" doesn't really mean anything as it does not define
> intended purposes of a cert, while "Client Authentication" does.
>
> It's the extension definition that matters. Which is why you have to
> like the way Thawte says:
> " Please note that the extension options below are not for the faint
of
> heart. You probably won't trigger a Vogon invasion of Earth if you
> press
> the wrong button, but you might cause weird behaviour in some
> otherwise-normal software. Don't fiddle with this unless you've been
> told to, or unless you're a born fiddler."
>
> t
>
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > Sent: Friday, August 24, 2007 11:54 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: SSL Client Certificate Authentication with
> non-
> > web clients
> >
> > But you still fail to define the "client". What "client" are you
> > referring to?
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx]
> > On Behalf Of Thor (Hammer of God)
> > Sent: Friday, August 24, 2007 1:27 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-web clients
> >
> > You can rage against the machine all you want, but the MSFT
> > nomenclature
> > specifically calls out "Client Authentication" vs. "Server
> > Authentication" as do most CA entities... Specifically, it would be
a
> > "client certificate" that exists within the context of a user,
> service,
> > or machine certificate store, depending on which context is
> performing
> > a
> > given function.
> >
> > t
> >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > > Sent: Friday, August 24, 2007 8:15 AM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > > So is this a machine "client", a service "client", a user "client"
> or
> > a
> > > "client client"?
> > >
> > > Client cert makes no sense. However, machine certificate makes
> sense,
> > > and user certificate makes sense.
> > >
> > > Just say NO to dopey nosology
> > >
> > > Thomas W Shinder, M.D.
> > > Site: www.isaserver.org
> > > Blog: http://blogs.isaserver.org/shinder/
> > > Book: http://tinyurl.com/3xqb7
> > > MVP -- Microsoft Firewalls (ISA)
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx
> > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor
> > > > (Hammer of God)
> > > > Sent: Thursday, August 23, 2007 5:41 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> > > > with non-web clients
> > > >
> > > > I figga'd you say something about that..
> > > >
> > > > "Client Certificate" is ISA's nomenclature. A "Machine
> > Certificate"
> > > > *can* be a client cert, but in this case, a client cert is a
cert
> > > with
> > > > the role of "Client Authentication" as opposed to "Server
> > > > Authentication."
> > > > t
> > > >
> > > > > -----Original Message-----
> > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > > > > Sent: Thursday, August 23, 2007 2:19 PM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re: SSL Client Certificate
> > > > Authentication with non-
> > > > > web clients
> > > > >
> > > > > What's a "client cert"? You mean like the machine certificate
> > > > installed
> > > > > on an L2TP/IPSec VPN client used for mutual authentication?
> > > > >
> > > > > Thomas W Shinder, M.D.
> > > > > Site: www.isaserver.org
> > > > > Blog: http://blogs.isaserver.org/shinder/
> > > > > Book: http://tinyurl.com/3xqb7
> > > > > MVP -- Microsoft Firewalls (ISA)
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: isapros-bounce@xxxxxxxxxxxxx
> > > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G.
> > > Young
> > > > > > Sent: Thursday, August 23, 2007 3: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.
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
>
>
>
>
Other related posts:
