Virtual Host type, named or IP via SSL? Named VH is not possible?
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Virtual Host type, named or IP via SSL? Named VH is not possible?
I am adding E Commerce webserver (Interchange) for a limited number of clients (less than 100). To serve, I now use Named Virtual Hosts which works well. Maybe? when I try to use SSL, Certificates etc., and add Ecommerce then this will not work. Does this mean I will need an IP addr for EACH client and use IP addr Virtual Hosting to function?
My general layout
RH 8, Apache 2, MySql, PHP, OpenSSH, djbdns
thank you for the help,
the ~piratebiter~hisself
Gee, I hope that moderator has more fun in high school this year, than he did with the trite sophmorish reply?
Why can't I use SSL with name-based/non-IP-based virtual hosts? [L]
The reason is very technical. Actually it's some sort of a chicken and egg problem: The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to dispatch to the correct virtual server Apache has to know the Host HTTP header field. For this the HTTP request header has to be read. This cannot be done before the SSL handshake is finished. But the information is already needed at the SSL handshake phase. Bingo!
Still never answers the ? Says No, you can't do it, ok then how about a little direction on HOW you do acomplish this. If the reason is "very techinical" maybe he had no clue?
Usually I get a lot of good info here, there are exceptions I guess.
Says No, you can't do it, ok then how about a little direction on HOW you do acomplish this.
If you use name-based VH's, then the VH is in the headers of each request. Based on the "Host" header the server seeks the corresponding VH. With SSL, the WHOLE request is encrypted, garbled, obfuscated. This means the server has NO access to the Host header before authentication is set up, so the server has NO clue which VH the request should be assigned to.
AFAIK in your situation IP-based VH is the way to go (the 3rd but unusable form of VH being port-based). In short: point the domains' CNAME's to the IP of the VH server, bind the IP's to your public eth, then configure each VH with its own cert. *There's also something like "wildcard certs" but I'm not familiar with them and from what I've read they're rather expensive.
Finally, your expressions of frustration and ineptitude clearly have no bearing on who I am or what I wrote. Please read up on basic netiquette and to try remain respectfull towards your fellow LQ members at all times.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.