|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Storing Client CertificatesIs 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 Hello Todd,
certs are no secret - a public key bundled with some extra info - why are you concerned with security? --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > 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 If someone hacked into the client machine and found the client cert they
could send form posts and/or files over to our server. So I wanted to "hide" the client cert so noone but my app either knows where it is or can get to it. Show quoteHide quote "Dominick Baier [DevelopMentor]" wrote: > Hello Todd, > > certs are no secret - a public key bundled with some extra info - why are > you concerned with security? > > --------------------------------------- > Dominick Baier - DevelopMentor > http://www.leastprivilege.com > > > 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 > > > > Hello!
You wrote on Wed, 23 Mar 2005 11:01:02 -0800: TB> If someone hacked into the client machine and found the client cert TB> they could send form posts and/or files over to our server. So I TB> wanted to "hide" the client cert so noone but my app either knows where TB> it is or can get to it. You can store the certificate in encrypted form and let the user enter the password. Of course, each user should have differently encrypted certificate. With best regards, Eugene Mayevski The client certificate or the private key for the client certificate? The
certificate is public information. The private key is needed to sign or authenticate and is the secret part. It is stored separately, or they are packaged together in a P12 file. We are probably just mixing up terms here, but technically the certificate really is public and can't be used to authenticate. Joe K. Show quoteHide quote "Todd Bright" <ToddBri***@discussions.microsoft.com> wrote in message news:B5D31332-D613-4ED0-83C3-6E4BCE7B31ED@microsoft.com... > If someone hacked into the client machine and found the client cert they > could send form posts and/or files over to our server. So I wanted to > "hide" > the client cert so noone but my app either knows where it is or can get to > it. > > "Dominick Baier [DevelopMentor]" wrote: > >> Hello Todd, >> >> certs are no secret - a public key bundled with some extra info - why are >> you concerned with security? >> >> --------------------------------------- >> Dominick Baier - DevelopMentor >> http://www.leastprivilege.com >> >> > 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 >> >> >> >> Hello Joe,
as i said - certificates are not secret. i guess you want to secure a private key in some form. if you have to deal with private keys in your application on the client you could encrypt the file (as suggested before) - this would require password entry on application startup (and this password will most likely end up for a long time in clear text in memory) - you could use DPAPI for enryption - this would leverage Windows single-signon. ...Or use the OS service that is specifically made for that : The Certificate Store container for storing certs/pub/priv keys, stored in user profile, roaming, uses single-signon. Have a look at CAPICOM - a COM lib to access the cert store - or use .NET 2.0 X509Certificate2, X509Store classes and friends. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > The client certificate or the private key for the client certificate? > The certificate is public information. The private key is needed to > sign or authenticate and is the secret part. It is stored separately, > or they are packaged together in a P12 file. > > We are probably just mixing up terms here, but technically the > certificate really is public and can't be used to authenticate. > > Joe K. > > "Todd Bright" <ToddBri***@discussions.microsoft.com> wrote in message > news:B5D31332-D613-4ED0-83C3-6E4BCE7B31ED@microsoft.com... > >> If someone hacked into the client machine and found the client cert >> they >> could send form posts and/or files over to our server. So I wanted >> to >> "hide" >> the client cert so noone but my app either knows where it is or can >> get to >> it. >> "Dominick Baier [DevelopMentor]" wrote: >> >>> Hello Todd, >>> >>> certs are no secret - a public key bundled with some extra info - >>> why are you concerned with security? >>> >>> --------------------------------------- >>> Dominick Baier - DevelopMentor >>> http://www.leastprivilege.com >>>> 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 Maybe I should back up here. From what I've read, the client-side cert is
generated based on the server-side cert and is used for authentication to access the web site on the IIS server. We are going to have several hundred (or thousand) clients accessing our servers. As an extra security measure we are going to use client-side certs in order to validate that a client accessing a web server is actually one of our installed clients and not just someone coming in thru a browser who "happened" upon the URL. I've tested this and if you tell your web site in IIS to require client certificates and the client doesn't have the appropriate client certificate the server will return an error page. Now, if someone hacks into the client's machine and is able to find the cert file (assuming it's stored on the HDD in its own file), the hacker will be able to do anything that our client application is doing (i.e. upload files). He will, in a sense, become our client application as far as the server is concerned. Am I way off base here? If so, what is the use of client certificates other than to authenticate with the server??? If not, my question still stands... what's a good way to store the client cert on the client machine so noone can get their hands on it and use it to authenticate themselves with the server? Show quoteHide quote "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 See comments below:
Show quoteHide quote "Todd Bright" <ToddBri***@discussions.microsoft.com> wrote in message news:7CE244BF-1B99-4441-A160-280B2E46DF54@microsoft.com... The client's have certificates AND matching private keys (probably managed> Maybe I should back up here. From what I've read, the client-side cert is > generated based on the server-side cert and is used for authentication to > access the web site on the IIS server. > > We are going to have several hundred (or thousand) clients accessing our > servers. As an extra security measure we are going to use client-side certs > in order to validate that a client accessing a web server is actually one of > our installed clients and not just someone coming in thru a browser who > "happened" upon the URL. > > I've tested this and if you tell your web site in IIS to require client > certificates and the client doesn't have the appropriate client certificate > the server will return an error page. Now, if someone hacks into the > client's machine and is able to find the cert file (assuming it's stored on > the HDD in its own file), the hacker will be able to do anything that our > client application is doing (i.e. upload files). He will, in a sense, become > our client application as far as the server is concerned. by CryptoAPI protected keycontainers .. linked to a userID). Access to that client's certificate private should probably be guarded by a password access to add additional "entropy" to accessing the certificate private key. Otherwise, any process running as that user, will have access to that client certificate's private key (and therefore may be able to access the SSL server automatically). BTW, when an SSL server requires a client's "certificate" what actually happens is the clients browser must digitally sign some data .. to PROVE that the client has access to the PRIVATE key associated with that client certificate. Accessing the client CERTIFICATE alone is not sufficient. -- Mitch Show quoteHide quote > Am I way off base here? If so, what is the use of client certificates other > than to authenticate with the server??? If not, my question still stands... > what's a good way to store the client cert on the client machine so noone can > get their hands on it and use it to authenticate themselves with the server? > > > > "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 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. Show quoteHide quote "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 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 Show quoteHide quote "Todd Bright" <ToddBri***@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 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. Show quoteHide quote "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" <ToddBri***@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 > > > 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 Show quoteHide quote "Todd Bright" <ToddBri***@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" <ToddBri***@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 > > > > > > 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). Show quoteHide quote "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" <ToddBri***@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" <ToddBri***@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 > > > > > > > > > > > > That is essentially it. This is the thing that tends to trip people up the
most often with using the ClientCertifcate property on HttpWebRequest or the web service client classes. Even though you specify the X509Certificate, the private key for that certificate must be installed and configured on the local machine in order for the SSL auth to work. Since the private key is generally associated with the user profile (although it can be associated with machine as a whole), you often run into deployment issues along those lines. So, in order to do what you are trying to do, you'll need to ensure that you get the private key for the certificate deployed properly, where "properly" depends on the details of how your application will run. No worries on the terminology. It takes a while to get the whole PKI thing as it seems like a lot of the documentation assumes you already know this stuff. Joe K. Show quoteHide quote "Todd Bright" <ToddBri***@discussions.microsoft.com> wrote in message news:D12DEDAB-ECF0-4891-9E57-B1B2EB045D58@microsoft.com... > 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" <ToddBri***@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" <ToddBri***@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 >> > > >> > > >> > > >> >> >> Trying to find out how to install the cert/PK onto the client machine without
it being dependent on who's logged on. In Certificate Server if I choose "Use local machine store" after choosing "Advanced Request", will that allow the PK to be user-independent? Show quoteHide quote "Joe Kaplan (MVP - ADSI)" wrote: > That is essentially it. This is the thing that tends to trip people up the > most often with using the ClientCertifcate property on HttpWebRequest or the > web service client classes. Even though you specify the X509Certificate, > the private key for that certificate must be installed and configured on the > local machine in order for the SSL auth to work. > > Since the private key is generally associated with the user profile > (although it can be associated with machine as a whole), you often run into > deployment issues along those lines. > > So, in order to do what you are trying to do, you'll need to ensure that you > get the private key for the certificate deployed properly, where "properly" > depends on the details of how your application will run. > > No worries on the terminology. It takes a while to get the whole PKI thing > as it seems like a lot of the documentation assumes you already know this > stuff. > > Joe K. > > "Todd Bright" <ToddBri***@discussions.microsoft.com> wrote in message > news:D12DEDAB-ECF0-4891-9E57-B1B2EB045D58@microsoft.com... > > 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" <ToddBri***@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" <ToddBri***@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 > >> > > > >> > > > >> > > > >> > >> > >> > > > Hello Todd,
yes. that should work. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > Trying to find out how to install the cert/PK onto the client machine > without it being dependent on who's logged on. In Certificate Server > if I choose "Use local machine store" after choosing "Advanced > Request", will that allow the PK to be user-independent? > > "Joe Kaplan (MVP - ADSI)" wrote: > >> That is essentially it. This is the thing that tends to trip people >> up the most often with using the ClientCertifcate property on >> HttpWebRequest or the web service client classes. Even though you >> specify the X509Certificate, the private key for that certificate >> must be installed and configured on the local machine in order for >> the SSL auth to work. >> >> Since the private key is generally associated with the user profile >> (although it can be associated with machine as a whole), you often >> run into deployment issues along those lines. >> >> So, in order to do what you are trying to do, you'll need to ensure >> that you get the private key for the certificate deployed properly, >> where "properly" depends on the details of how your application will >> run. >> >> No worries on the terminology. It takes a while to get the whole PKI >> thing as it seems like a lot of the documentation assumes you already >> know this stuff. >> >> Joe K. >> >> "Todd Bright" <ToddBri***@discussions.microsoft.com> wrote in message >> news:D12DEDAB-ECF0-4891-9E57-B1B2EB045D58@microsoft.com... >> >>> 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" <ToddBri***@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" <ToddBri***@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 Thanks for everyone's help and patience!!!
Show quoteHide quote "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 
Other interesting topics
Re: RSA Encrypt/Decrypt Problems
License File Generator Using Digital Signatures Difference between Full Trust and Everything Re: full trus and 1.1 SP1 Howto obtain WindowsIdentity for client calling method on COM+ application? SecurityCritical, SecurityTreatAsSafe and SecurityTransparent Attributes? ildasm Re: Error instantiating RSACryptoServiceProvider Howto obtain WindowsIdentity for client calling method on COM+ application? Bouncy Castle C# crypto port |
|||||||||||||||||||||||
