It's fine for any box to store or cache certificates of any kind.
Certificates are public data, and only contain a public key.
I know that it's fine - am just describing the setup, mostly for the
benefit of those who tend to jump to conclusions and give others as
little credit as possible under the circumstances.
urimobile> NOW Windows box claims that it holds NOT ONLY the server's
urimobile> public key (which was expected), but ALSO the server's
urimobile> PRIVATE KEY.
This is the first time you said that *another* device's private key
ended up on your Windows box.
And you "naturally" ASSumed that I complained about both private and
public keys ending up on the machine _that owns that key-pair_. Thank
you very much. On the other hand, we tend to judge others by our own level.
And still, that can't happen because of a CSR, which is what you claimed was at
fault.
I never mentioned CSR. I simply stated that openssl-based CA seems to
deal more freely with others' private keys than normal security would
suggest, and that somehow one party's private key ended up on a
different box. From both (a) "openssl req" requiring private key which I
didn't think necessary, and (b) Windows box that received somebody
else's cert claiming to now be in possession of that somebody's private
key - I concluded that openssl is "guilty", and that private key ended
up in the wrong hands because the "request" - the *_only_* thing that
travels from the "victim" machine to the CA - somehow communicated it.
If in your opinion private key traveled via different means (not within
the "newreq.pem" bundle that contained private key as I showed you) -
please share the info with me.
For those who've had enough of this - a short technical summary:
/At least two demoCA sripts - CA and CA.pl - add user private key to
the signature request they prepare for sending to the CA (which IMHO is
wrong, no matter what Rich Salz says :-). CA signs the PubK in the
request, but leaves the rest of the bundle "unmolested". As a result,
unsuspecting user ends up with his private key traveling from his box
via CA to the recipient of his cert (assuming for whatever reason he
chooses to install the certs on the peers, rather than let the peer to
retrieve them online). It looks like a bug to me./
However, it seems you found something:
You can say so, thank you.
(I assume, BTW, that you used CA.pl here)
Correct.
And I don't know if this is the only place - I simply brought up the
most obvious and easiest to notice. There could be other places that I
didn't know to look into.
urimobile> Looks like it concatenates private key and the actual cert
urimobile> request together.............
....................................
I'd call that a bug, that's not the way it should be, in my opinion
(translated: that's completely f*cked!).
Yes this certainly is not the way it should be. And even though it's a
_demo_ CA, still IMHO it shouldn't do things like that.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
