Re: Certificates, users and machines
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
Re: Certificates, users and machines
Hello, 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? Yes. 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? You can do this in SSL callback or after SSL netgotiation. After SSL_accept() returns, you are sure that SSL client authentication end successful (provided that you configured SSL server to request that :-) and that certificate is verified (valid time, signature ...). After that you can in your application get client certificate from SSL object: cert = SSL_get_peer_certificate(ssl); and next get some info from cert: name = X509_get_subject_name(cert); name = X509_get_issuer_name(cert); serial = ASN1_INTEGER_get(X509_get_serialNumber(cert)); some info may be converted to text and printed: X509_NAME_oneline(name, buf, sizeof(buf)); X509_NAME_oneline(name, buf, sizeof(buf)); with this info you may decide to accept certificate or not to accept ... If you decided to not accept: shutdown SSL connection. 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. Of course you can issue one certificate and give it to some people for authentication purpose. Technically this will work. But with certificate you must give private key too (in reality this key is used to client authentication is SSL). If in one place this private key will be compromised than you have to generate new key/certificate and give it to ALL users. If in one place this private key will be compromised than you have to disable this certificate on server and this will disable your ALL clients. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificates, users and machines
Urjit Gokhale wrote: It seems that you are making the common mistake of conflating authentication with authorization. Certs are useful in binding pubkeys to identities and subsequently in verifying possession of the private key by being able to perform decryption. The SSL protocol has provision for client_auth, which means that the server and client must each present a cert. If this is the case, need_client_auth is communicated in the handshake, along with a list of DNs of CAs trusted by the server. The client must present a cert or cert chain which is rooted in one of those CAs. ... is it necessary to issue ONE certificate to EACH individual. Yes. The problem of granting access based on membership in a group is an authorization problem. This doesn't have anything to do with certificates -- permissions and roles change independently of binding of key to identity. LDAP, flat files, /etc/group, etc. You could have a hierarchy, with a subordinate CA for each role or group, if you want to manage it that way. I wouldn't. - Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Certificates, users and machines
... is it necessary to issue ONE certificate to EACH individual. Yes. The problem of granting access based on membership in a group is an authorization problem. Correct. This doesn't have anything to do with certificates -- permissions and roles change independently of binding of key to identity. LDAP, flat files, /etc/group, etc. Mostly correct. Often is convenient to have not only identity - but also attributes of it certified. I.e. for the sake of the argument identity Michael may have an attribute employee of Tenebras, and another attribute permitted access to dev repository A12. I'm driving at Attribute Certificates. They are supposed to have shorter life than identity certs, but still long enough to be usable. You could have a hierarchy, with a subordinate CA for each role or group, if you want to manage it that way. I wouldn't. He would have to have attribute CA's for each attribute - not necessarily for each value of the attribute. I.e. an attribute CA Personnel Department could issue attribute certificates employed in position X, granted access to resource Y... The question of whether attribute certs are better or worse for authorization than e.g. flat files is similar to whether cert-based identity authentication is better or worse than e.g. LDAP-based one or flat files e.g. Unix /etc/passwd. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificates, users and machines
Mouse wrote: I.e. for the sake of the argument identity Michael may have an attribute employee of Tenebras, and another attribute permitted access to dev repository A12. Well, the Subject Distinguished Name should have the Organization, but I strongly disagree with you if you think access permissions belong anywhere in a cert. The question of whether attribute certs are better or worse for authorization than e.g. flat files is similar to whether cert-based identity authentication is better or worse than e.g. LDAP-based one or flat files e.g. Unix /etc/passwd. Attribute certs are a lousy way to encode security policy. You really only need signed assertions if the relying party has no trusted method of communication with the policy server (file/db/etc). Revocation is a pain, certificate status is a pain, and you've just multiplied your public key computation load by a factor of three of four. Much better to check whether the authenticated party has permission to do what's requested at the time of the request. Group membership is questionable -- the OU is certainly a kind of group, but for the purposes of access control a party may belong to many groups, and a robust policy might restrict access to certain hours during certain days of the week. If you seriously consider this, then the idea of putting access controls in certificates really looks absurd. - Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificates, users and machines
Thank you very much for the response. For both the responses I got, it looks like the server need to access the information (whether identity or attribute or whatever) present in the certificate and use that to decide the permissions for the peer that represented this certificate. Is my understanding correct? Yes. The problem of granting access based on membership in a group is an authorization problem. This doesn't have anything to do with certificates -- permissions and roles change independently of binding of key to identity. LDAP, flat files, /etc/group, etc. I also agree that this is authorization problem. I was just trying to get information on whether certificate handling in openssl restricts me from issuing certificates to a group instead of individuals. I guees I know it now. Mostly correct. Often is convenient to have not only identity - but also attributes of it certified. I.e. for the sake of the argument identity Michael may have an attribute employee of Tenebras, and another attribute permitted access to dev repository A12. I'm driving at Attribute Certificates. They are supposed to have shorter life than identity certs, but still long enough to be usable. You could have a hierarchy, with a subordinate CA for each role or group, if you want to manage it that way. I wouldn't. He would have to have attribute CA's for each attribute - not necessarily for each value of the attribute. I.e. an attribute CA Personnel Department could issue attribute certificates employed in position X, granted access to resource Y... Sounds good. Now, my server will be expecting a few specfic attributes in the certificate presented by peer, in order to regulate access to different services, right? So the question is which APIs in openssl allow me to access this information in the certificate? Also, it will be really great if someone could explain the default certificate verification process in openssl. Thank you once again for your response. ~ Urjit 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RE: Certificates, users and machines
On 2007.05.25 at 08:16:19 -0400, Mouse wrote: I'm driving at Attribute Certificates. They are supposed to have shorter life than identity certs, but still long enough to be usable. I've seen project to add attribute certificates to OpenSSL. http://openpmi.sourceforge.net/ You can try to download patches from this project and adapt to use in yu environment. It seems that they have very preliminary version which must be cleaned up to work on all platforms OpenSSL supports. The question of whether attribute certs are better or worse for authorization than e.g. flat files is similar to whether cert-based identity authentication is better or worse than e.g. LDAP-based one or flat files e.g. Unix /etc/passwd. Typically requirements for authorization and authentication are very different. Authentication involve untrusted networks, passwords which can be stolen or forgotten etc. But once you trust authentication, decisions about authorization of authenticated users for certain operation are typically within your server system. But if there are RFCs for attribute certifications, TLS authorization extensions etc, there should be situation when cryptography-based authorization is needed. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Certificates, users and machines
Well, the Subject Distinguished Name should have the Organization... Can you envision long-lived certs issued by gov't - like passports? In that case, Organization would not have the same semantics. But this is less relevant for our discussion. ...but I strongly disagree with you if you think access permissions belong anywhere in a cert. It appears to be convenient to have _separate_ certs - called ATRIBUTE certs - that carry that information. More convenient than other means of conveying this same information. In the above example - identity cert is your passport issued by (for the sake of the argument) USA, attribute cert issued by a different authority is your visa to enter (for the sake of the argument) India issued by Indian consulate and with life-time shorter than your passport. Attribute certs are a lousy way to encode security policy. Matter of taste. You really only need signed assertions if the relying party has no trusted method of communication with the policy server (file/db/etc). Of course. Just like you really only need identity certs if the relying party has no trusted method of communicating with authentication server. I.e. if everything in your shop (and other shops you're communicating with) is Kerberized - you don't need PKI. Revocation is a pain, certificate status is a pain, Of course. That's true for *all* the PK issues - be it identity or attribute certs. and you've just multiplied your public key computation load by a factor of three of four. No, you merely double it. One - check that the identity cert is valid, two - that the attribute cert that *you* are interested in (out of a dozen that may be attached to this identity cert) is OK. Much better to check whether the authenticated party has permission to do what's requested at the time of the request. Authentication and authorization are very disticnt and different things. Nonetheless, checking permissions is not that different from checking authenticity. For example - what means are there to check authenticity? And to check authorization? Group membership is questionable -- the OU is certainly a kind of group, but for the purposes of access control a party may belong to many groups, and a robust policy might restrict access to certain hours during certain days of the week. The idea is that credentials that are long-lived and are meaningful more-or-less universally (identity and - to a lesser extent - employment) seem to fit well in the identity cert. Credentials that have shorter life, but still somewhat persistent (and meaningful across localities) - would fit in the attribute certs. And credentials that are not meaningful outside of local environment and/or are very short-lived - probably are better served by online query to the policy server. ...[from a different post]...Authentication involve untrusted networks, passwords which can be stolen or forgotten etc. But once you trust authentication, decisions about authorization of authenticated users for certain operation are typically within your server system. If the only credential necessary for authorization decision is requestor's identity, and all the policy information is readily available online - then yes. Imagine a situation in the future: you are coming to a car dealer and present your identity cert plus an attribute cert issued by a bank that says owner of identity cert X has been approved for a loan for a new car in amount of up to $XX valid till XXX. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Certificates, users and machines
For both the responses I got, it looks like the server need to access the information (whether identity or attribute or whatever) present in the certificate and use that to decide the permissions for the peer that represented this certificate. Is my understanding correct? Partially so. An Attribute Certificate is a _separate_ certificate that becomes meaningful only when presented together with the identity cert. Its purpose is to be able to add and remove certified attributes to an identity cert, without having to re-issue the identity cert itself. I also agree that this is authorization problem. I was just trying to get information on whether certificate handling in openssl restricts me from issuing certificates to a group instead of individuals. I guees I know it now. The answer is - yes it does [restrict]. Sounds good. Now, my server will be expecting a few specfic attributes in the certificate presented by peer, in order to regulate access to different services, right? That would be one way of doing it... In design you should balance the expense of the authorization process against convenience of its use. I.e. are you going to authorize users based on credentials vouched by a 3rd party? If not - then somehting like a local policy server is a more elegant and computationally cheaper solution. So the question is which APIs in openssl allow me to access this information in the certificate? I'm afraid OpenSSL hasn't implemented Attribute Cert support yet. So the above discussion is moot from practical point of view. You'd need to search on the Net for one of a couple of OpenSSL enhancements that implement it (still in development stage), or use a policy server-based approach. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Certificates, users and machines
and you've just multiplied your public key computation load by a factor of three of four. No, you merely double it. One - check that the identity cert is valid, two - that the attribute cert that *you* are interested in (out of a dozen that may be attached to this identity cert) is OK. Not even that, because you save the cost of determining authorization some other way. The other common way is some kind of secure connection to an authorization box. one extra PK computation is probably less costly than that. (And if you cache the certificate's validity, you only need to do that once on a given server for a given user.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
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
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificates, users and machines
On 2007.05.16 at 16:03:38 +0530, 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. Almost true, but user never generates certificate. User generates certificate signing request (CSR), and send it to CA. CA generates certificate, and can add or remove some information from user request. It is CA's signature under certificate and it is up to CA to decide which information to certify with it. * The certificates are signed by some entity (CA), just to assure that association between the public key and the other information is correct. This helps in identifying the authenticity of the certificate. True Now, I state what *I believe* is true in case of PKI and certificates: 1) A private key-public key pair created, can be Typically, user generates key pair, and never discloses private part of it to any authority. That is why it is called private. a) given to a specific user, b) stored on a specific machine. (By some authority ?) If you are speaking about server keypair (i.e. one which identifies https server), key pair and CSR are typically generated by system administrator of this server. 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 can know that user 'xyz' is communicating with it. This is _probably_ user 'xyz' unless somebody stole his private key. (if user 'xyz' noticed theft, he should notify CA and CA would revoke certificate. This is why checking of CRL (Certificate revokation list) or online validation via OCSP protocol is important. 3) in the second case, any user using that particular machine can use the key pair to communicate (assuming he has access rights). The other end, on Typically, nobody except root or user under which appropriate server is invoked, has access rights for private key. Because if any untrusted person can read this key, he can transfer it to some other machine and impersonate machine in question. seeing 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? Certificate (and CSR) has so called Distinguished name property. This property is list of name-value pairs. There is a list of standard field names which such as Country, Location, Organization. Most important one is Common Name. If we are generating certificate for user, Common Name should contain name of this user. If we are generating certificate for server (machine), Common Name should contain DNS name of this machine. Machine can have multiple IP addresses and multiple names associated with each of them. Typically server certificate validation works following way: 1. User gives its client software an URL which includes server name to connect to. 2. Software resolves name via DNS to IP address. 3. Software connects to this address and starts TLS handshake 4. Server which listens on the address sends its certificate. 5. Software (i.e OpenSSL library) checks that certificate is signed by proper CA using certificate store, provided in the software configuration. 6. CN field of certificate should be compared with server name given in URL. Since OpenSSL library doesn't have access to URL - it recieves already connected socket, it cannot do it itself. So it is up to application which uses library. how can a peer authenticate / validate this particular certificate? Could someone please provide a sample validation callback function code? There is no need to use callback. Default callback is good enough. You can just wait for successfull completion of handshake, then obtain peer (server) certificate via SSL_get_peer_certificate (or SSL_get_peer_cert_chain) function as X509 structure, extract distingushed name using X509_get_subject_name function, and then get CN field from it using X509_NAME_get_text_by_NID function and passing NID_commonName constant as nid parameter. Also, 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
Re: Certificates, users and machines
I hope this information helps. -Kyle H Thank you for your response and information about the proxies. I now have a feeling that to write a verification callback function, I will need to retrieve the information stored in the certificate that the peer has sent to me. If you want to make HTTPS connection, take a look a libcurl, at least you can get inspried by the code tat validates a server certficate. It is not a callback, it does it after the handshake. So now, the follow-up questions are: 1) If my server has not received any certificate so far, how can it request for it? It depends on the CA, it depends on whether you have hardware keys etc. 2) Once the certificate is available to my program, how can I retrieve the information in the certificate? I believe , given that the certificate is in a particular format (x509 ?), the information can be retrieved as a C structure (or something alike), which then can be used to test each individual piece of information. Could you point me to APIs that will allow me to achieve this? See above (libcurl) in ssluse.c Thanks, ~ Urjit 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
