Agreed - the ftp client has no need for the ftp server's private key. The client only needs the server's certificate or the CA cert. The certs have the public key and a signature of that public key by the CA above it in the chain. Server certs don't contain private keys, and the client doesn't need them.
BUT: if this vendor is giving you its server's private key, then the server is *not* secure. This is because when you connect to that server you don't know if you are really talking to the vendor or someone else, since anyone with the private key could impersonate the server. You should never trust exchanging information with this server. On Thu, Aug 22, 2019 at 3:22 PM Charles Mills <charl...@mcn.org> wrote: > Customers are probably not relying on it. The key has no place in the > protocol flow. It is gratuitous, superfluous information. > > The vendor simply replaces the certificate(s) everywhere, keeping the > private key of the new certificate(s), well, private. > > Then the vendor revokes the compromised certificate(s). > > This process must be applied at whatever level the key applies to. If they > have an in-house CA and are distributing its private key, then they must > start over with a new CA and revoke every unexpired certificate issued by > the old CA. Similar logic if the distributed an Intermediate Certificate > key. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Thursday, August 22, 2019 12:42 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: vendor distributes their private key > > On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote: > > >Thanks all for the response. I'm glad I wasn't missing something. I > will discuss further with the vendor, hoping they will recognize the risks. > > > How can the vendor recover from this without causing great > disruption, even an indefinite time in the future, to existing > customers who are rely on the improperly distributed private key? > > ---------------------------------------------------------------------- > 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
