Still no response :-( Could someone please help me clarify my doubts? thanks, ~ Urjit
----- Original Message ----- From: "Urjit Gokhale" <[EMAIL PROTECTED]> To: <openssl-users@openssl.org> Sent: Thursday, May 24, 2007 4:28 PM Subject: Re: Certificates, users and machines > Thanks for your reply. > I would like to have your opinion on one scenario, and my approach to > provide needed functionality: > 1) I have a server that listens to connection requests from the clients over > the internet (meaning anyone and everyone who knows my ip/port can send me > connection request. I am not behind a proxy). > 2) I trust a CA (my_ca). So I have this CA's root certificate, which I can > use to verify client certificates. > 3) I wish to service client requests coming only from a particular group. So > I need client authentication. > > Now, if I do not specify any certificate verification callback in the > server, any and every client who has a certificate signed by 'my_ca' will be > able to connect to me, because by default (I believe) openssl will only > verify that the client certificate is authentic (signed by trusted CA). Is > this understanding right? > > Assuming that this is true, I will 'have to' specify a callback that will > actually validate the certificate presented by the client, by looking at > information other than the public key present in the certificate, right? How > do I retrieve this information from the certificate? Could someone point me > to APIs which retrieve this information from the certificate? > > considering that retrieving and validating certificate information is > possible, can I (rather the trusted CA my_ca) issue ONE unique certificate > to a bunch of people(this means giving the same private-public key to all > these people), such that they represent a group that my server is interested > in entertaining? This question arises as I need to clarify if it is possible > to issue ONE certificate to multiple individuals, or is it necessary to > issue ONE certificate to EACH individual. > > > Thanks, > ~ Urjit > > > ----- Original Message ----- > From: "Kyle Hamilton" <[EMAIL PROTECTED]> > To: <openssl-users@openssl.org> > Sent: Wednesday, May 16, 2007 4:45 PM > Subject: Re: Certificates, users and machines > > > > A certificate binds the public key of a public/private (asymmetric) > > key pair with additional information. > > A certificate is trusted by some trusting authority. In most cases, > > this is a certifying authority (CA) -- and the asymmetric signature > > by the CA is an assertion that the CA believes that the binding is > > correct. > > > > The additional information can relate to the user, or the user > > +machine, or machine itself, or literally any other combination. For > > purposes of your question, though, it relates to these three options. > > > > The certificate is never, ever used in isolation. It is used in > > conjunction with the private key, at a minimum, but it may also be > > used with protocol data. (i.e., machine address.) > > > > I am unable to provide you with sample code for this purpose. > > However, I must warn that there exist software proxies which are > > capable of masking the true originating host. (If you wish to be > > certain that a connection is from a host in your IP range, for > > example, you must ensure that a proxy software is not in place on > > that host.) You can perform such a check by getting the peer's > > address on the connection in question... and then verifying that the > > host is valid. (You can do this from information stored in the > > certificate, or from information stored in a database that only the > > verifier has access to.) > > > > You may also verify a given computer based on its IP, versus > > information stored in the certificate and signed by your CA. Again, > > the 'proxy' problem asserts itself, but such an attack might be more > > sophisticated. > > > > Regardless, there exist no 100% guarantees. You must weigh the value > > of any given attack versus the cost of that attack, and set your > > policies appropriately.) > > > > I hope this information helps. > > > > -Kyle H > > > > On May 16, 2007, at 3:33 AM, Urjit Gokhale wrote: > > > > > Hello everyone, > > > > > > I have some doubts about certificates, which I wish to get > > > clarification on. > > > > > > Here is my understanding about certificates: > > > * Certificates bind the public key with some other information like > > > the name= > > > of the owner(user), who generated the certificate, the validity > > > period etc. > > > * The certificates are signed by some entity (CA), just to assure > > > that assoc= > > > iation between the public key and the other information is correct. > > > This hel= > > > ps in identifying the authenticity of the certificate. > > > > > > Now, I state what *I believe* is true in case of PKI and certificates: > > > 1) A private key-public key pair created, can be > > > a) given to a specific user, > > > b) stored on a specific machine. (By some authority ?) > > > 2) In the first case, the user can take the keys with him, and use > > > these for= > > > communication from any machine. The other end, on seeing the > > > certificate ca= > > > n know that user 'xyz' is communicating with it. > > > 3) in the second case, any user using that particular machine can > > > use the ke= > > > y pair to communicate (assuming he has access rights). The other > > > end, on see= > > > ing the certificate can know that someone from machine > > > 'abc.def.ghi.jkl' is= > > > communicating with it. > > > > > > Is this understanding correct? > > > If yes, I would like to know how can I generate a certificate that > > > binds the= > > > public key with a particular username or a particular machine? > > > how can a peer authenticate / validate this particular certificate? > > > Could so= > > > meone please provide a sample validation callback function code? > > > > > > Also, > > > > > > DISCLAIMER=0A= > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= > > > This e-mail may contain privileged and confidential information > > > which is the= > > > property of Persistent Systems Pvt. Ltd. It is intended only for > > > the use of= > > > the individual or entity to which it is addressed. If you are not > > > the inten= > > > ded recipient, you are not authorized to read, retain, copy, print, > > > distribu= > > > te or use this message. If you have received this communication in > > > error, pl= > > > ease notify the sender and delete all copies of this message. > > > Persistent Sys= > > > tems Pvt. Ltd. does not accept any liability for virus infected mails. > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List openssl-users@openssl.org > > Automated List Manager [EMAIL PROTECTED] > > > DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
