Difference between revisions of "User:Woozle/2017/08/16/https subdomain issue"
| Line 1: | Line 1: | ||
| + | ==Final Fix== | ||
| + | The .conf file for vbz.net apparently needed to be rebuilt. Through VirtualMin, I removed SSL support from vbz.net, then added it back in; this seems to have fixed the problem via wireless (and yes, I can confirm that the connection is using IPv6 -- which also breaks my session table just a bit, so it's GOOD that this happened). | ||
| + | |||
==Partial Solution== | ==Partial Solution== | ||
Somehow, the ''link'' to /etc/apache2/sites-available/vbz.net.conf in sites-enabled had been replaced by an actual file, so updates to the sites-available version were not actually being implemented. I replaced the file with the proper link, reloaded Apache, and everything started working properly. | Somehow, the ''link'' to /etc/apache2/sites-available/vbz.net.conf in sites-enabled had been replaced by an actual file, so updates to the sites-available version were not actually being implemented. I replaced the file with the proper link, reloaded Apache, and everything started working properly. | ||
Latest revision as of 14:06, 17 August 2017
Final Fix
The .conf file for vbz.net apparently needed to be rebuilt. Through VirtualMin, I removed SSL support from vbz.net, then added it back in; this seems to have fixed the problem via wireless (and yes, I can confirm that the connection is using IPv6 -- which also breaks my session table just a bit, so it's GOOD that this happened).
Partial Solution
Somehow, the link to /etc/apache2/sites-available/vbz.net.conf in sites-enabled had been replaced by an actual file, so updates to the sites-available version were not actually being implemented. I replaced the file with the proper link, reloaded Apache, and everything started working properly.
With my cellphone connection, however, the problem remains.
Test links:
Problem
At first, this only happened when trying to access the site via my cell connection; at home, everything worked fine.
As of today, the problem seems to have propagated to my home connection as well (though this may be because of the config fix I tried).
The problem is that while http://vbz.net brings up the correct web site, https://vbz.net responds as if I have requested https://cloud.vbz.net (which is on the same server, configured through Virtualmin as a subdomain of vbz.net).
This does not seem to be browser-dependent. Here are results from wget:
woozle@SamEagle:~/scratch$ wget https://vbz.net/admin --no-check-certificate --2017-08-16 18:45:17-- https://vbz.net/admin Resolving vbz.net (vbz.net)... 192.81.211.103, 2604:a880:400:d0::14c7:1 Connecting to vbz.net (vbz.net)|192.81.211.103|:443... connected. WARNING: no certificate subject alternative name matches requested host name ‘vbz.net’. HTTP request sent, awaiting response... 404 Not Found 2017-08-16 18:45:18 ERROR 404: Not Found.
Trying the same thing from Firefox shows that the certificate it receives is correct for cloud.vbz.net; if you ignore the mismatch, you get content from https://cloud.vbz.net.
...and here's what that wget request looks like on the server side:
==> ./cloud.vbz.net_access_log <== 50.111.158.155 - - [16/Aug/2017:22:45:18 +0000] "GET /admin HTTP/1.1" 404 4590 "-" "Wget/1.17.1 (linux-gnu)"
So clearly Apache has somehow decided that I'm requesting cloud.vbz.net when I request vbz.net -- but only when I request it through https.