Hey John,
i got it working… but only on my network. It is really hard to keep track of all this stuff. To test sometimes I have to unplug one eth to make sure it isn’t going to let packets in that way… but some cards won’t work/route against the lo with it unplugged from the hub/switch. So, I have to plug it into a switch all by itself. Plus the firewall gets in the way, changing gateways, forgetting which is currently active, etc.
You sure were right about being better off without all the private ip stuff.
Yes, this is actually the kind of tricky stuff I was encouraging you to avoid. And the forgiving nature of Linux routing across local NICs is actually a hindrance when things get complicated (because you end up thinking all of this jiggling of wires and ports and switches is how you should make it work, when in fact, you ought to be getting the routing tables, masks, etc. right, which makes it work for everyone, not just the Linux box itself). You can get as complicated as you want, and Linux will accommodate, but you need to learn a lot about routing to get it right. Adding NAT to the routing picture makes it even harder.
anyways… as usual, you’re right joe. But this is all your fault… (just kidding) :0), but I wish you would have put it in the docs that needing a separate ip meant public not private.
I figured it didn’t make any difference, but I guess I didn’t make it clear that the problem you have to solve is end-to-end connectivity, not fooling Apache or Virtualmin into serving or setting things up–it’s not the software you have to convince…it’s the protocol, which insists on end-to-end connectivity (anything else looks like a man-in-the-middle attack to the client). Apache will happily serve SSL on as many domains as you want, but it’ll always look like whatever domains certificate you’re using. That’s bad security, and removes half of SSLs purpose (identity), so we don’t do it.
If you want multiple SSL domains with actual security, you need multiple IP addresses. There is a future without this problem, but it’s not one that you or I can solve–the browser and webserver have to support newer protocols. I don’t think any version of either do so today.
I’m thinking that re-validating servers, and many other things may go haywire if I try to leave these four domains under the control of Virtualmin.
No, of course not. If you setup SSL hosts outside of Virtualmin they don’t affect Virtualmin at all, and Virtualmin doesn’t affect them. That’s why, among other things, Virtualmin is the best damned thing going in this space.
Setup as many SSL VirtualHosts outside of Virtualmin as you like. Virtualmin won’t give one whit about them. You can even manage them in the Apache module, if you want. Virtualmin doesn’t care.
2. That is the biggest reason I bought the pro version is so that it could set up apache, mail, virus, spam, dns… so, now that I got all those so close to what I want; then I guess I could just delete the server, but choose the option to just remove it from the control of virtualmin. There are a lot of ongoing services that I will miss out on if I choose to do this… so if there is anyway to set up NameVirtualHost *:443 directive for a host or two…it’d be a plus. Will just saving these directive in apache somewhere else… then deleting and starting over with namebased - then copy/paste the directive into apache’s config cause problems?
Hmmmm…I have no idea what you’re asking here, but it sounds bad.
Don’t go deleting stuff or removing it from the control of Virtualmin–you lose so much capability for ongoing maintenance. I’d never wish that on anyone.
You’re assuming Virtualmin is preachy and bossy. It isn’t. It really really isn’t. It’ll do what you tell it, and it won’t break the stuff you add to Apache outside of Virtualmin, even within the VirtualHost sections that Virtualmin manages! Though there could be conflicts in directives.
If you want to do what I think you want to do (I’m having a hard time keeping up!), do it this way:
[ol]
[]Create your domains. Get 3.36 of Virtualmin so you can create one as SSL.[/]
[]Edit httpd.conf.[/]
[]Copy the VirtualHost sections that don’t have SSL counterparts.[/]
[]Convert them to SSL sections, by moving them to ip:443, and adding certificate directives–all pointing to the same certificate. Pretty much just mirror the one SSL domains directives right over to all of the other domains.[/]
[/ol]
Now, the domain itself and its contents (mailboxes, scripts, PHP4/PHP5, etc.) are controlled by Virtualmin. Your SSL hosts, except the first, are outside of Virtualmin’s control, but you’ll rarely need to do anything to them (but you should keep an eye on the non-SSL ones to be sure any directives get ported over when Virtualmin adds them for scripts and such (or scripts installed with Install Scripts won’t work).
3. why did you say that I cannot even have one of my hosts on the same IP as the namebased *:80 and that this will change later… I don’t see anything stopping it now.
Virtualmin prior to 3.36 assumed nobody would want to put SSL hosts on the same IP as their shared hosts. 3.36 will allow you to setup one SSL host on a system that only has one IP. Just an assumption borne out of a history of being used in large hosting environments. Some of our Early Adopters are in much smaller environments, often without spare IPs, so we’ve now accommodated that particular situation.
Oh, yeah, I wanted to address this, as well:
Also, the apache website says you can use the NameVirtualHost directive as much as you want. It shows examples that use the complete ipv4 and ipv6 address and port num. But it didn’t help. No one from the public side will be able to request these websites unless they can come to the one public IP and then tell it that it really wants a private IP… well browsers don’t do that! I’ve found that there is a way to have a reverse proxy that passes the right requests back/forth between my local network and the public. That’s a lot of hassle and I saw a few were doing this to save on certificate costs. They call it tunnelling.
Again, this is a routing problem. Apache will work fine on any number of private addresses mapped to public ones (your VirtualHost sections need to specify the private addresses–not the public ones). You get the requests from the outside to the inside via correct routing and NAT, and Apache will do the right thing with the requests. It sounds like you may not have the routing infrastructure in place to meet that requirement. No proxies are needed, thought proxies are great for some situations (my previous company was a proxy appliance vendor…I’m a big fan of proxies in their right place…but you don’t need proxying…just correct routing and NAT).
Browsers don’t need to do anything special, nor does Apache. If you route/NAT correctly between the two, neither will even know about the difference.
Linux, all by itself, can provide the routing infrastructure needed to do what you want. It has one of the most amazing routers on the market built right in to it. But, you’d have to give Linux one or both of your public IPs. And then you no longer have this particular set of problems to solve! Your only problem then would be getting your internal PCs out to the world…that one is easy. IP Masquerading in Linux is magically simple. There’s a great HOWTO about it here:
http://tldp.org/HOWTO/IP-Masquerade-HOWTO/