How to create SSL sites on *:443 instead of ip_address:443 ?

15 posts / 0 new
Last post
#1 Wed, 07/17/2013 - 03:33
Dr. Moe

How to create SSL sites on *:443 instead of ip_address:443 ?

Hi All,

Hope that some of you have already come across this issue. It's 2013 and SNI is now supported by most major browsers.

Yet, Virtualmin will create VirtualHosts that support SSL as: xx.xx.xx.xx:443.

Wile this may be perfectly applicable in most setups, it seems to bring quite some confusion when the Virtualmin host is an Open VZ virtual machine behind DNAT and /or when apache already uses *:443 elsewhere.

In such a setup, where the Virtualmin host is configured with an internal LAN address and the Virtualmin module is configured to create sites over the external IP address 'DNATed' to the Virtualmin Host, the first SSL site takes precedence in the order shown by apache2ctl -S.

According to some quick tests, changing all Apache vhosts to use external_ip:443 (and external_ip:80) does not solve the issue.

On the other hand, setting all vhosts to reference *:80 and *:443 works like a charm.

Unfortunately, I have failed so far to find how to configure Virtualmin so that it will automagically create SSL sites as .

Does anyone know if such a configuration setting would actually be available ? If not, might there be a way to modify the xx.xx.xx.xx:443 vhosts created by webmin using some built-in automation ?

Obviously, I would very much prefer not to set up a system-wide shell script in a cron job, since it'as a waste of resources and implies a delay for end users.

Has anyone managed to create SSL sites as '*:443', or may anyone direct me towards the relevant config entries ?

Wed, 07/17/2013 - 09:01
andreychek

Howdy,

There is a way to get Virtualmin to use *:443... you'll probably want to do both of the following to get Virtualmin to do that --

Change the NameVirtualHost entries you have to use *:443

Change the first (default) VirtualHost entry in Apache to use *:443

After doing both of the above, it should create new VirtualHost entries using that format.

-Eric

Wed, 07/17/2013 - 10:23 (Reply to #2)
Dr. Moe

Hi Eric,

Unfortunately not.

Virtualmin actually creates a NameVirtualHost entry upon site creation, using whichever address is found in the Virtualmin Module Configuration / Network Settings page.

I did follow your suggestion, made sure there were only wildcard NameVirtualhost entries in /etc/apache2/ports.conf, restarted apache and proceeded to creating a new domain.

Two more NameVirtualHost entries appeared in /etc/apache2/ports.conf, and the new vhost was created as 'VirtualHost external_ip:443'.

I then tried to fiddle with the Virtualmin Module Configuration / Network Settings page and came up with these saddening results :

  • not specifying OpenVZ's external interface explicitly results in the creation of VirtualHost and NameVirtualhost entries bound to 127.0.0.2

  • removing the external IP address from the 'Virtual server default IP address field' results in the creation of entries bound to the internal (LAN) address for the host (if OpenVZ's venet0:0 interface is specified in the 'Default NIC' field above)

  • attempting to use the '*' wildcard as in any of these fields gets rejected as 'invalid value'.

  • and obviously, specifying the 'proper' (external) address on this page reverts to the behaviour I first described, with NameVirtualHost and VirtualHost entries bound to the external IP.

So your advice seemed to point me in the right direction, but there I'm stuck again and at a loss.

Any further ideas ?

From what I've seen so far, Virtualmin heavily insists on knowing which IP address virtual servers shall respond to.

Since Virtualmin's module config also allows to specify an IP address for DNS records, this single entry would fulfill my needs if I could find any way for SSL vhosts not to be bound to any IP upon creation.

Since I assume Eric must have tested his suggestion before writing, and since Virtualmin actually begs for an external IP or will deduce one from the host's network setiings, I've begun to wonder if the issue may be Wheezy related (the host is running Debian 7.0), since all relevant OpenVZ and Nat-related params would need to be filled the same in any other setup.

Thu, 07/18/2013 - 07:56
andreychek

Well, rather than *:443, would it work to just place multiple SSL certs on one particular IP address?

Virtualmin does support SNI... so even while using x.x.x.x:443, you can have multiple SSL certs on that IP.

Virtualmin can create *:PORT style VirtualHost entries, though I haven't tried that with your specific setup before.

-Eric

Thu, 07/18/2013 - 08:52 (Reply to #4)
Dr. Moe

Hi Andry,

Thanks for your answer.

Moving all vhosts to external_ip:443 (and external_ip:80) was my my first move. It seemed like the obvious thing to do, all the more so as the virtualmin host only uses one external IP address.

And it failed. FWIW, all vhosts ceased to respond to internet requests. Subsequent attempts with the host's internal IP address failed in the same manner.

Still, the DNAT rules, which in plain English state : 'redirect requests to some_port on external ip to matching_port on internal IP', seem to be fine, since all virtual servers properly respond as long as all vhosts bind to '*:443'.

Which is why I stated in my first post that 'VirtualHost *.443' was appparently a requirement for this environment.

And it works, but manual intervention is required right after virtual server creation.

There is indeed no issue with Virtualmin's SNI support per se, only with virtual server creation.

Granted, it is not much work to manually adapt any newly created virtual server so that its SSL vhost references '*:443' rather than some IP, but the issue remains as soon as one must delegate virtual server creation to end users (and not sysadmins)... which is exactly my work case, unfortunately.

Understandably, I do not want to either need to keep an eye on the host to find out if or when a new virtual server was created, I'd much rather avoid an angry customer's call complaining that SSL does not work, and as I mentioned before, I believe that scheduling a shell script with cron in order to achieve the task is only a somewhat confusing misuse of resources.

Any further suggestions before I must resort to coding ?

Thu, 07/18/2013 - 09:38
andreychek

Howdy,

After reading your most recent post, and re-reading your initial post a few times, I do think I understand better what's going on.

It's sounds like what you're trying to do may not work for one reason or another... it's possible that Virtualmin requires the port 80 and 443 entries to match (I can ask Jamie the specifics here, though he's out of the country at the moment).

However, it sounds like something else is going awry, as you shouldn't need *:PORT entries if you only have one IP address.

That is, using NAT is a common thing -- lots of folks use SSL on that, and it should be no problem to use x.x.x.x:80 and x.x.x.x:443 on one IP address, and have that work properly.

So assuming I understand what's going on (which may be a large assumption :-), we may be able to resolve the issue you're seeing a different way.

Since you're on NAT, you wouldn't want Apache to have VirtualHost entries containing your external IP address -- they would need to contain your server's internal IP address.

Assuming I'm not missing or misunderstanding something here -- and feel free to correct me if I am -- what you may need to do is to look in System Settings -> Virtualmin Config -> Network Settings, and verify that "Default virtual server IP address" is set to "From Network Interface", and that "Default IP address for DNS records" is set to "Automatically detect external address".

If the IP addresses being added were external and not internal, that would cause the behavior that I believe you're describing.

Now, if there's other entries that already exist on your system -- we'll, we'd need to change those :-)

To keep Apache from getting confused as to which VirtualHost entry to serve, you'd probably need to update all the IP addresses that are listed in Apache's various VirtualHost sections, if they're currently incorrect.

Does the above address your issue? Or am I still not understanding what's going on?

-Eric

Fri, 07/19/2013 - 02:31 (Reply to #6)
Dr. Moe

Hi Eric,

Thanks for taking the time to analyze and answer. Your understanding is perfectly correct :-)

And you have definitely pointed me in the right direction.

Upon reading your post, I assumed I may have overlooked something during my orignal testing. So I did make sure that all relevant apache directives would reference external_ip:80 and external_ip:443, and this time it worked.

Which definitely means I must have left some discrepancy over during my previous test runs. All apologies for this.

Therefore the '*:443' can be be deemed SOLVED !! Many thanks :-) !!!

Yet, there still remains a related issue which for now prevents me to hand the server over to end users : virtual server creation now requires that the external ip address be specified at creation time in the 'IP addresses and forwarding section', in either 'Network interface' or 'External IP address' field.

Much easier and more convenient indeed, but still overkill for my end users (sigh..).

Please let me know if I should create a different post / issue on this.

I believe this should again come frome some config mistake on my side, but have no idea where to correct this.

FWIW, the external IP address the virtualmin host uses is but one of several addresses the datacenter provider agreed to route to the physical host. Hence, virtualmin may never detect the proper external IP, and will instead offer the physical host's main IP.

In order to follow Eric's advice, I had to fill the virtualmin module config's 'Network settings page' as follows, or Virtualmin would mistakenly detect the hypervisor's main IP as the external address :

  • Network Interface card : venet0:0
  • Default IP address for virtual servers : internal_ip (although 'From network interface' would probably reap the same results)
  • Default IP address for DNS records : external_ip

Now, where should I turn for to set the proper external IP to become default at virtual server creation time ?

Sun, 07/03/2016 - 22:13
s31tech
s31tech's picture

I am also running into this same problem. Virtualmin is great, I really love the tool, but there are a few quirks I'm still trying to work out. This being one of them.

What's happening is that if I create a new website and I don't enable SSL on it, it creates the site without a problem...If I go to the Apache config (under the webmin menu) I see that the site is there, listening on Port 80 and that the ip address says "Any".

If I go to that same website that's already been created under the virtualmin menu and I enable SSL for it....It will not work...If I go into the Apache config after that point...I notice that instead of saying "Any" like port 80, it says "127.0.0.1".

If I go into the global apache configuration and I set this specific site as a virtual host (examplesitename.conf) to be *:443 instead, it totally works. But I am wondering where the settings are originally generated, because no matter what, if I set a site to use SSL, it HAS TO use the ip address of the server instead of wildcard, which is really annoying..

Trying to find the difference between regular and SSL and how those config files are generated. Why does it generate different parameters with SSL but not with regular http?

In this screenshot, this is what it looks like...Every site says "ANY" because I manually set them that way, but you can see that a new fake site that I created, automaticaly puts SSL in there with a specific ip address. If the ip is set to 127.0.0.1...The site I'm trying to do SSL on wont work until I change it to *:443 in the config file.

HERE's what it looks like: https://s31tech.org/wp-content/uploads/2016/07/apache-ssl-weird.png

All of the sites except butterkitten.com (fake site) are configured properly, but I had to manually set them to those settings for https...If I create a new website it looks exactly like butterkitten.com in my screenshot where it will put "Any" for port 80, but will put a specific ip address for port 443.

BUT if I set the shared ip of the server to be it's real ip instead of 127.0.0.1...Then when I create a new SSL site, it will break every other SSL site on the server until I go into the config file to change that one site to be *:443 instead....Really scratching my head on this one.

These are the settings of virtualmin by default...Rebuilt a totally new server, tested on totally default/new config on a new VM and same results. I'm sure it's something really really stupid but still not able to find it after a few weeks off and on.

Mon, 07/04/2016 - 17:43 (Reply to #8)
unborn
unborn's picture

and you running this on distro??

Configuring/troubleshooting Debian servers is always great fun

Wed, 07/13/2016 - 09:37
ibuyweb

under virtualmin configuration, goto section "Actions upon server and user creation"

create or add the following script to "Command to run after making changes to a domain"

#!/bin/sh
if [ "$VIRTUALSERVER_ACTION" = "CREATE_DOMAIN" ]; then
#apache sni fix
cp -f /etc/httpd/conf/httpd.conf  /etc/httpd/conf/httpd.conf.bak
sed "s/$VIRTUALSERVER_IP:443/*:443/g" /etc/httpd/conf/httpd.conf > tmp_file
mv tmp_file "/etc/httpd/conf/httpd.conf"
service httpd restart
fi

if [ "$VIRTUALSERVER_ACTION" = "MODIFY_DOMAIN" ]; then
#apache sni fix
cp -f /etc/httpd/conf/httpd.conf  /etc/httpd/conf/httpd.conf.bak
sed "s/$VIRTUALSERVER_IP:443/*:443/g" /etc/httpd/conf/httpd.conf > tmp_file
mv tmp_file "/etc/httpd/conf/httpd.conf"
service httpd restart
fi

the script makes a backup of your current apache config then search/replace current IP that's attached to :443 to *:443 then restart apache.

this is a automated solution for sni breaking on domain creation or modification.

Note: Make sure to modify "/etc/httpd/conf/httpd.conf" to point to your apache config location. I'm using CentOS 6.8

Mon, 07/18/2016 - 14:06
s31tech
s31tech's picture

My build is Debian. I am having a hard time finding the equivalent of httpd.conf on Debian. is it named something different on debian? When I tried it under /etc/apache2/apache2.conf it broke the server (luckily I made a snapshot), that might be the wrong file entirely though. I think your script would work if I knew the debian equivalent.

Mon, 07/18/2016 - 15:37
Diabolico
Diabolico's picture

On Debian is "/etc/apache2/apache2.conf" and while there is httpd.conf file it is not used and instead the main conf is apache2.conf file. I'm not good with this OS but i think httpd.conf is there just for compatibility with other software.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.

Tue, 07/19/2016 - 19:23
s31tech
s31tech's picture

Ah ok, apache2.config is what i tried with the same script but it broke the whole web server (internal server error). But I think it's on the right track, but it seems like it's modifying the wrong file...Should be modifying individual site configs which are in their own folders...But I don't see where a new website would be grabbing it's config from apache2.conf because it looks totally different.

But what I'm wondering is when a virtual server is created for the first time, where does it grab those settings initially to where it shows up with *:80 for http but shows up as xxx.xxx.xxx.xxx:443 for https, causing me to have to manually change config file on every site creation.

Wed, 07/20/2016 - 15:17
ibuyweb

you probably should read https://debian-handbook.info/browse/stable/sect.http-web-server.html

the config file for each debian vhost would be:

"/etc/apache2/sites-available/$VIRTUALSERVER_DOM.conf"

Fri, 08/12/2016 - 06:01
alanf

Whilst I probably could write the script to loop through the Virtual servers and sed the 443 entry, it would be really nice if this could be fixed.

It doesn't just impact Amazon servers, the same applies to Google Cloud Compute servers where the Fixed IP is NATed and the internal IP not reliable.

It seems inconsistent to be able to get *:80 but not *:443

Topic locked