On Tue, Dec 30, 2008 at 02:26:20PM -0500, Edward Diener wrote: > Victor Duchovni wrote: > >On Mon, Dec 29, 2008 at 12:55:14AM -0500, Edward Diener wrote: > > > >>My assumptions from what I could glean from the certificates distributed > >>is that the CA-cert.pem is the same for client and server, while the > >>server-cert.pem is a public key corresponding to the private > >>client-key.pem, and the server-key is a private key corresponding to the > >>public client-cert. When I say "corresponding I mean that they form a > >>public-private key pair. > > > >No it is simpler than that: > > > > For each (one or a few) server: > > - a server-cert.pem corresponds to a server-key.pem > > - in some deployments all servers share the same server cert and key > > - best practice is to generate the server keys on the server, and > > then obtain a CA cert for the public key (certificate request). > > > > For each (often many) clients: > > - a client-cert.pem corresponds to a client-key.pem > > - each and every client key and corresponding certificate pair > > are distinct from all other such pairs. > > - best practice is to generate the client keys on each client, and > > then obtain a CA cert for the public key (certificate request), > > you need to bootstrap secure (authenticated) delivery of the client > > CSR from the client to signing CA. The CA need not be a public > > CA, there is often little value in using a public CA in this > > context. > > - Client certificates are OPTIONAL. You can just encrypt the > > connection to the server and login with username/password. > > Makes sense. Thanks for the info. > > > > >In fact from all the noise in this thread, it seems that simplicity is a > >major win whenever complexity is confusing, so dispense with the client > >certs entirely and go with username/password. TLS will just encrypt > >the login session and authenticate the server. > > In this last case I do not understand how the client can encrypt data > going to the server if it has no private key of its own.
And yet it is possible, read up on Diffie-Hellman key-exchange. And learn more about SSL/TLS. You browse "https" websites with no private key of your own... > >Your confusion is not OpenSSL confusion, it is basic lack of experience > >with public/private key security protocols and the roles the various > >keys play. > > > >Neither OpenSSL users, nor GnuTLS users, nor Microsoft CryptoAPI users, ... > >are specifically the right people to burden with your question. > > Are these certificates specifically SSL certificates or are they more > broadly public key-private key certificates ? SSL != OpenSSL. And X.509 certificates are applicable more broadly than OpenSSL (e.g. IPSec and S/MIME). > >This is a general question about communication's security and requires > >independent research via books or a general security help forum. > > For what books do I look to specifically understand how these > certificates work with public key-private key pairs ? SSL books ? > Cryptography public key-private key books ? I am perfectly willing to > learn, since I am a very fast learner, but I need to know where > specifically to look. I do not want to have to learn all the details > about computer security and cryptography, although that might be > interesting in and of itself, but I do want to understand all the > details about public key-private key and certificates. > > Unfortunately the MySQL documenation offers very little, which was the > main reason for my OP on this NG. This mailing list is primarly for programmers developing applications that incorporate the OpenSSL APIs. Users of SSL-enabled products should generally seek help elsewhere, unless there is a specific issue with OpenSSL tools used in conjunction with said SSL-enabled products. The list is called "OpenSSL-users", not "SSL-users". -- Viktor. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org