> From: owner-openssl-us...@openssl.org On Behalf Of "Martin v. Löwis" > Sent: Sunday, 21 October, 2012 15:35
> Am 21.10.12 19:25, schrieb Tom Browder: > > I have successfully generated SSL client certificates for my Apache > > web site users, <snip> > > One thing I'm not sure of is why there is a private/public > key pair in the client certs. <rescinded elsethread> > > You must be misinterpreting what you are seeing. The certificate > data structure isn't capable of storing private keys, so if you see > the private key embedded somewhere, it's not a "client cert" it is > embedded in. > Not quite. X509v1 and v2 can't contain a privatekey. v3, and PKCS#? CSR, support extensions that allow you to add any data if you get all relevant parties to implement or ignore it. It would be appallingly stupid to put privatekey in an extension, and contravene the whole purpose of having certs, but it would be possible. openssl does not define or have code to support any such extension, but you could do it in custom code or with the "raw" DER support. > > Hopefully it's not the same private key used to generate the CSR, > > or is it? > > The private key to generate a CSR for a certificate is the > CA's private > key. So if you have a separate CA, then no, it's not the same key. > If you are using self-signed certificates, revoking them is not > possible. > ITYM the CSR is signed by the *entity* privatekey; the *cert* is signed by the CA privatekey. To add the other half to what you say, for selfsigned these entity and CA keys are the same (and you don't really need a CSR), otherwise they are different. > > In any event, why is it needed? > > > > All I am using the certs for is to allow access to my site which is > > done by (as I understand it) Apache checking that (1) the > client cert > > hasn't been revoked and (2) it has been signed by me as the CA. > > The web browser also needs access to the private key, as a proof that > it really represents the identity that is mentioned in the cert. > Otherwise, anybody could copy the certificate from the wire, or from > some directory service (it's really public). > > The server shouldn't have the private key at all - the private > key should never leave the machine on which the browser is running. > Yes/maybe. If you generate the keypair and CSR on the client and send the CSR to the CA and get back the cert, the privatekey can and should be only on the client -- except you might want an encrypted or otherwise protected backup, so when the PC dies you don't have to start over. If you don't have (convenient) tools and sufficiently competent users on the clients -- which does happen in the real world -- another method is to generate the keypair and CSR for each client (separately) on a trusted central party, get a cert, and provide each client the (unique) privatekey and matching cert to use. Typically -- especially for web browsers -- this is in the form of a PKCS#8 aka PFX. A private CA like the OP implies is trusted anyway and has the tools to be such a "key provider". To deserve this trust, it must either destroy or protect these privatekeys after issuance, and certainly should never give them to anyone else, except someone authorized, such as the police with a subpoena -- at least if your police are reasonably honest, and if not you have bigger problems than SSL. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
