On Wed, Apr 9, 2008 at 2:10 PM, David Schwartz <[EMAIL PROTECTED]> wrote: > > > Thanks Kyle, > > > > Here is my situation: > > > > I have a server which can sign certificates over tls(implemented in > > both client and peer). > > > > I generate a public/private key pair for each peer now. > > > > I need a way so Peer A Trusts Peer B because. > > > > So, I am trying to figure out the best way to do this, can server sign > > each peers certs and them trust each other? > > Yes. The usual way to do this is: > > 1) Peer connects to server. > 2) Peer and server exchange whatever information is needed for server to > confirm peer's identity. > 3) Server issues peer a signed certificate that vouches for its identity. > 4) Peer disconnects from server. > 5) Peer connects to peer. > 6) Peer presents certificate it got from server. > 7) Other peer validates certificate and knows peer's identity as established > with the server. (It must also determine that the peer *owns* the > certificate as opposed to just having a copy of it!) > > This requires the peers to be able to recognize that a certificate was > signed by the server and is properly owned by the peer they're talking to.
More specifically: Each peer has a copy of the CA's public certificate. That's what allows this to work. Each peer goes through this process: 1) peer creates a keypair 2) peer generates a CSR (certificate signing request) for its public key. 3) peer connects to server, submits CSR along with whatever information necessary to determine that the certificate should be issued. 4) Server signs the certificate with its private key, and sends signed certificate back to peer. peer and server disconnect. Then, on peer-peer connection: 1) peer(listener) presents its own certificate, requests peer(connector) certificate from same CA. 2) peer(connector) verifies peer(listener)'s certificate (and proof that it has the private key paired with the pubkey in that certificate), presents its own certificate. 3) peer(listener) verifies peer(connector)'s certificate (and proof that it has the private key paired with the pubkey in that certificate). Each peer has a copy of the CA certificate in its trusted root authorities store. When they receive a peer certificate, they verify the signature on that certificate as being from that CA, and then verify that the peer that it's talking with actually has the private key associated with that certificate. Then they look at the information in that certificate (expiration date, etc). This is what TLS with client authentication does. The 'key' that you need to include with your binary is actually the CA's certificate (which contains the CA's public key). You don't need to include any 'trusted' information in the client other than that, and you don't need to include any 'secret' information at all. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
