So you do name based virtual hosts with SSL and without SNI? I would love to see your config files! - As always you teach us lowly mortals so much ;) On Fri, Aug 13, 2010 at 11:38 PM, Lisa Kachold wrote: > I have never heard so much various misinformation in my life! > > On Fri, Aug 13, 2010 at 9:49 PM, Eric Shubert wrote: >> >> Thanks Russ. You're once again a great sanity check. :) >> -- >> -Eric 'shubes' >> >> R P Herrold wrote: >>> >>> On Fri, 13 Aug 2010, Eric Shubert wrote: >>> >>>> I don't necessarily believe everything I see, and would like to check on >>>> something I read. >>>> >>>> Is the following statement true or false? >>>> >>>> "SSL requires a distinct outbound IP for every distinct certificate >>>> (different domain name)." >>> >>> Clearly technically not true, but not in the way you probably expect -- >>> One can have a SSL certificate for the purposes of securing web content, and >>> a separate one for the purpose of securing email transfer -- check the >>> headers of this piece, whch use a StartSSL [highly recommended] certificate >>> for opportunistic SSL layer transport of content >>> >>> If you had added the qualifier 'for a given protocol (TCP) and port (443) >>> pair', it would be true in the usual case, absent heroic and non-customary >>> approaches >>> >>>> My understanding is that multiple hosts with distinct certificates could >>>> coexist behind a NAT'd firewall on a single public address and still provide >>>> SSL connections via the public address. >>>> >>>> Would someone who's more knowledgeable than I about this care to shed >>>> some light on the subject? >>> >>> I assume web connection here.  I put to one side a 'wildcard' certificate >>> where several boxes all offer a connection secured by a single credential. >>>  TLS/SSL protected email to multiple clients using differing certificates, >>> as the negotitaion occurs 'late enough' that one could 'hand off' a >>> connection, perhaps, to a second unit inside a load balancer, to complete >>> the SSL/TLS connection setup. >>> >>> The flaw with a webbish (port 443) delivery in your setup is based on >>> when in the request the secured connection is set up >>> >>> The negotiation and establishment of the SSL tunnel occurs BEFORE any >>> hostname part (indeed, any part) of the URL is transmitted.  How would the >>> NAT device know which credential to offer?  How can the remote end verify >>> that an offered certificate is not on a recovation list at the CA? >>> >>> If a connection were established to point A on the outside, with a 301, >>> 302 type redirector to  a 'new' URL 'inside' it might be doable as a new >>> secured connection setup can occur, and if there is low volume and a unique >>> client IP at the far end, but this cannot be counted upon ... >>> >>> I see a suggestion tht a Level 3 router can sniff the request and do >>> internal direction.  I am aware of no such mechanism to do this only up to >>> L3 of the stack in a web session.  The needed session credentials are not >>> yet knowable at the time of the negotiation ond DH key exchange of the >>> session encryption key.  Once that session is set up, there is not a >>> mechanism for a 'handoff' of a running session, for that is the essence of a >>> Man in the Middle attack >>> >>> -- Russ herrold >> >> > > I setup SSL Certificates in NAT environments all the time. > > Various solutions are available: > > 1) Apache2 Name Based Virtuals > 2) /etc/hosts file utilization on the server > 3) split DNS for IP based virtuals > > It's not called Network Address Translation for nothing! > > This is very simple (you are thinking about this triangulated authentication > from a one sided point of view): > > If the IP ADDRESS matches the SSL CERT, DNS name and certificate called from > the browser to Apache2,  the content will be trusted.  It's just that > simple. > > Reference: > http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch20_:_The_Apache_Web_Server > > -- > Office: (602)239-3392 > AT&T: (503)754-4452 > http://it-clowns.com > "Faith is, at one and the same time, absolutely necessary and altogether > impossible. " > --Stanislav Lem > > > > > > > > > > > > > > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss