-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Covington schrieb: > Hi all, Hello Chris,
> Suppose one wants to secure a server application which accepts > incoming HTTPS connections from anywhere. We'll call this Server A. > This server application is intended to only accept connections from > other satellite server applications (say Server 1, 2, 3, etc.). The > end users' LAN-only application connects to these satellite servers, > and then the satellite servers pass on application data to Server A. > Essentially the end users' application does its job through the > satellite server (Servers 1, 2, 3, etc.) -> Server A HTTPS tunnel. > > My thoughts were in this scenario, the best way to implement (HTTPS) > SSL/TLS would be for Server A (with a server certificate) to only > accept HTTPS connections from Servers 1, 2, 3, etc. who have valid > client certificates, rather than hardcoding some kind of > username/password into Servers 1, 2, 3, etc. to connect to Server A > who accepts anonymous TLS connections from anywhere. That seems indeed the best way to solve the given problem. > Then the implementation involves distributing certificates / private > keys to Servers 1, 2, 3, etc. and ensuring Server A's HTTPS server > only establishes TLS sessions for clients with valid client > certificates, not just anyone ala hotmail. Thanks to Mr. Duchovni it > appears the term I'm searching for these password-encrypted client > certificates / private keys bundles is pkcs12. This pkcs12 > distribution would be done offline to Servers 1, 2, 3, etc. Generating the servers private keys and certificates on the server A and distributing them to the servers 1, 2, 3 etc. in PKCS#12 files is one possible way to do this. Assuming the servers 1, 2, 3 etc use this certificate / private keys only to authenticate against server A I see no security problems. > Now I believe Victor mentioned these pkcs12 bundles should not be used > in place of a username / password for Servers 1, 2, 3, etc. to connect > tIn the SSL handshake the client has already proved that he owns the matching private key for the identity in the certificate. o Server A. If so, what else needs to be done? Should Server A also > require a username and password for Servers 1, 2, 3, etc. as well as a > valid client certificate? Or should a username map to a pkcs12 > bundle? Why should server A require user name and pass phrase from the clients ? In the SSL handshake the client has already proved that he owns the matching private key for the identity in the certificate. (otherwise done with the pass phrase) The data in the client certificate (usually the subject name (and in there the common name entry)) identifies the connected client. (otherwise done with the user name) Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZb0r2iGqZUF3qPYRAqSeAJ96QQqnY6PEs0H9e5s/LYqvMPDqagCeLlKa 6Rd8TBp63Qht81kXbkAB38I= =kijw -----END PGP SIGNATURE----- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
