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 [email protected]
Automated List Manager [email protected]
