Re: X.509 Certificate based authentication
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 22 May 2007 15:48:22 -0500
Inline below
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
<gudujarlson@xxxxxxxxx> wrote in message
news:1179863543.183821.41120@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On May 22, 10:13 am, "Joe Kaplan"
<joseph.e.kap...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Thanks for your response. If the subject is guaranteed to be unique,
how do you explain the subject of "localhost" I obtained from a
commercial CA? Is it because subject is not unique on 30-day
evaluation certificates? Is it documented anywhere that subject is
unique? Should I look for such a guarantee on the CA's website? I've
looked around a couple websites and I have not found such a
guarantee. Why does makecert.exe allow me to create certificates with
non-unique subjects? I'm not saying you're wrong. I'm just wondering
why this fact is not stated very clearly somewhere.
I guess I should say that it is not typical for a CA to issue a client
certificate with a duplicate name, but I suppose it could happen. Like
Dominick said in his other post, the only thing that is guaranteed to be
unique is the public key, so that or the thumbprint or subject key
identifier would need to be used to tell different certs with the same
subject apart. What I should have said was that the subject (or the subject
alternative name) is the only thing you get from the cert that gives you any
identity information about "who" owns the private key for the cert's public
key.
Do you know how this works? Does IIS map the public key to a windows
user? The subject? Something else? How does IIS identify a
certificate uniquely?
IIS has some flexibility in how it does this as you can create your own
mappings in IIS to control this. At the AD level, the cert can contain an
alternate name with the user's AD UPN in it or the AD user object might have
the cert's subject set up as an alternate security identity name. To be
honest, I've never done a lot with cert mapping to Windows users, so this
isn't an area where I have a ton of expertise.
What you say makes common sense to me, however an experiment I did
does not support this. I exported my client certificate without the
private key and then passed the public-key-only certificate along with
my HTTPS call (System.Net.HttpWebRequest.ClientCertificates.Add). IIS
accepted the certificate and mapped it to a windows user ID. I
expected it to not accept it since the caller did not have the private
key. One guess is that the .NET framework looked up the private key
in the cert store even though I did not pass it in.
This should not have been possible. You can't do client certificate
authentication unless you have the private key available. Are you certain
that the private key was not available when you did this? If you ran this
code on the same machine, it is likely the case that the .NET client just
looked up the certificate you supplied in the file in the store on your
machine and accessed the private key that way. The file just serves as a
hint on how to look up the private key. Thus I think your guess is correct
here.
.
- References:
- X.509 Certificate based authentication
- From: gudujarlson
- Re: X.509 Certificate based authentication
- From: Joe Kaplan
- Re: X.509 Certificate based authentication
- From: gudujarlson
- X.509 Certificate based authentication
- Prev by Date: Re: X.509 Certificate based authentication
- Next by Date: Re: X.509 Certificate based authentication
- Previous by thread: Re: X.509 Certificate based authentication
- Next by thread: Re: X.509 Certificate based authentication
- Index(es):
Relevant Pages
|
|