Thanks, excellent description!
On Apr 9, 2008, at 2:22 PM, Kyle Hamilton wrote:
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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
