Re: Storing Client Certificates
From: Todd Bright (ToddBright_at_discussions.microsoft.com)
Date: 03/24/05
- Next message: Joe Kaplan \(MVP - ADSI\): "Re: Windows Authentication question"
- Previous message: Natan: "Re: Windows Authentication question"
- In reply to: Michel Gallant: "Re: Storing Client Certificates"
- Next in thread: Joe Kaplan \(MVP - ADSI\): "Re: Storing Client Certificates"
- Reply: Joe Kaplan \(MVP - ADSI\): "Re: Storing Client Certificates"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 24 Mar 2005 12:05:02 -0800
Ah, I see. So the private key, in my case, would need to be installed on the
client's machine in the local machine store to be independent of who is
actually logged in the the Windows OS. It's really the machine that we're
validating, not the user. And when we generate the client cert, we need the
certificate to be physically separate from the private key pair (not a P12
file)?
I would then use the code that I provided to send the client cert (without
the PK pair) over to the server and then the behind the scenes flow would
work like in your last post. Is that correct? Sorry for being so dense, but
this is one area that I know very little about and that I find very confusing
(probably from lack of terminology).
"Michel Gallant" wrote:
> You NEVER send your private key over the wire .. ever.
> What happens "behind the scenes" below when you invoke
> an SSL connection requesting client certificates is:
> locally, the security manager (underlying capi ) searches for
> a matching PRIVATE key to the public key in your provided
> certificate file. The current user and local machine stores are searched
> for matching certificates with PRIVATE keys. If a certificate WITH
> A MATCHING private key IS found, then that private key is used to
> digitally sign some data and send that to the SSL server. This way, the
> server can ensure that yes, the person with that client certificate ALSO
> has the matching private key.
> So even if someone steals a client certificate, it is useless unless they
> steal your identity. The private key is protected by encryption based on
> yoru logged in credentials and other secrets (see DPAPI).
>
> So if you invoke the code below, on ANOTHER computer that has your
> public certificate as a file .. it will fail .. because they won't have your
> private key (unless you share your private key which you should never do).
>
> - Mitch
>
> "Todd Bright" <ToddBright@discussions.microsoft.com> wrote in message news:8FD68E35-5776-4F14-AC31-4BA137173A34@microsoft.com...
> > Thanks for the info. I'm not wanting to associate anything with a Windows
> > user. I just want to be able to programmatically send the client
> > cert/private key to the IIS server like I am a browser. I've tried using the
> > following code:
> >
> > HttpWebRequest myreq = (HttpWebRequest)WebRequest.Create(URI);
> > myreq.Method = "POST";
> > // Specify the client certificate
> > string CertFname;
> > X509Certificate cert = X509Certificate.CreateFromCertFile(CertFname);
> > myreq.ClientCertificates.Add(cert);
> >
> > This requires the cert to be pulled from a file. I don't want to install it
> > in the client's browser or anything like that, unless it's secure and I don't
> > have to supply user credentials to get it back out.
> >
> >
> > "Michel Gallant" wrote:
> >
> > > Yes, pkcs12 (.pfx, .p12 etc..) format is designed for portability of
> > > keypairs along with certificates and their chains ..
> > > Usually password-based encryption protects the private key therein (typically 3DES).
> > > A bit of a backgrounder on pkcs12 and .net:
> > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncapi/html/pkcs12.asp
> > >
> > > Some people have had security issues with that format however:
> > > http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html
> > >
> > > - Mitch Gallant
> > > MVP Security
> > > JavaScience Consulting
> > > www.jensign.com
> > >
> > > "Todd Bright" <ToddBright@discussions.microsoft.com> wrote in message news:4A6C86E9-9AA4-44D1-A15E-B77CA31F9A0D@microsoft.com...
> > > > After reading Joe's post a fourth time, it sound like the confusion is coming
> > > > from the way that we're generating the client certs (which I know very little
> > > > about). If, in fact, we are generating a P12 file as the certificate/private
> > > > key then both of these would be packaged in the same physical file, correct?
> > > > I just remember that there was a file that I was using to authenticate (maybe
> > > > it was a P12 file). Sorry for the confusion.
> > > >
> > > >
> > > > "Todd Bright" wrote:
> > > >
> > > > > Is there a way in .Net to specify that an embedded resource can only be
> > > > > accessed from within the assembly?
> > > > >
> > > > > Or, in general, what is the best/most secure way of storing a client-side
> > > > > cert without having to have a user profile?
> > > > >
> > > > > Thanks,
> > > > > Todd
> > >
> > >
> > >
>
>
>
- Next message: Joe Kaplan \(MVP - ADSI\): "Re: Windows Authentication question"
- Previous message: Natan: "Re: Windows Authentication question"
- In reply to: Michel Gallant: "Re: Storing Client Certificates"
- Next in thread: Joe Kaplan \(MVP - ADSI\): "Re: Storing Client Certificates"
- Reply: Joe Kaplan \(MVP - ADSI\): "Re: Storing Client Certificates"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
