> But for certificate-based client authentication, the server admin must send > the client admin a client certificate AND its private key.
Yes, he sends the client a key intended to be used only by that client. That's very different from a vendor sending his own private key to customers. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Charles Mills <charl...@mcn.org> Sent: Wednesday, August 28, 2019 7:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key I'm sure everyone is tired of this thread but I wanted to jump in here and say that anyone -- including me -- who said "you should never get a private key from the owners of some server you want to connect to" was potentially wrong. Yes, yes, of course, sending out root CA or Intermediate certificate private keys is wrong, wrong, wrong. Horribly wrong. Ditto "regular" server certificate private keys. But for certificate-based client authentication, the server admin must send the client admin a client certificate AND its private key. Why? Philosophically, because a client certificate signed by a trusted CA does not prove the authenticity of the client. A man-in-the-middle might have previously intercepted the certificate and now be sending it out from HIS client as its own. Practically speaking, the client authentication protocol requires the client to send a certificate-signed hash of all of the messages that have come so far on the startup handshake. The server validates that signature with the public key in the certificate. The client must have the private key to be able to do that, preventing the MITM attack I describe above. And the fact that it uses the current session messages as a unique input prevents a replay type attack. Here's a reference: https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication-part-1/ Yeah, yeah, it's Microsoft but X.509 is X.509, even when Microsoft does it. Other references say the same thing. This was just more clear and thorough IMHO. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel M Ivey Sent: Thursday, August 22, 2019 5:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: vendor distributes their private key A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
