Name-Based Virtual Hosts & SSL

Tamer Ziady

unread,

Mar 2, 2021, 4:52:24 AM3/2/21

to

Hello:

Using apache 2.4.46 on a FreeBSD 12.2 server. I am unsure if it is a bug or if I was somehow able to accomplish something that is not possible. A previous set up running on CentOS 8 had 5 Name-Based Websites each with their own SSL cert. This has been working without any problems for like 3 years. At any rate, recently set up a new box to migrate away from CentOS and being an old FBSD user; I figured I would go back. But that is another story.

Anyway, with the new installation after some changes here and there; I have 2 of the websites working perfectly fine. However, the last website is not able to accessed in anyway. It actually shares a Let's Encrypt Cert with one of the other sites.

Here are the virtual hosts entries:

<VirtualHost *:80>
ServerName www.domain1.com
Redirect permanent / https://www.domain1.com/
</VirtualHost>
<VirtualHost *:443>
ServerName www.domain1.com
ServerAdmin in...@xxxx.xxx
ServerAlias domain1.com
DocumentRoot /var/www/xxxx.xxx/
<Directory "/var/www/xxxx.xxx">
Options Indexes FollowSymLinks
require all granted
AllowOverride All
</Directory>
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/x-httpd-php
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip

SSLEngine on
SSLCertificateFile /path/to/fullchain.pem
SSLCertificateKeyFile /path/to/privkey.pem

<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>

BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>

<VirtualHost *:80>
ServerName support.domain2.com
ServerAlias support.domain2.us
Redirect permanent / https://support.domain2.com/
</VirtualHost>
<VirtualHost *:443>
ServerName support.domain2.com
ServerAlias support.domain2.us
ServerAdmin sup...@xxxx.xxxx.xxx
DocumentRoot "/var/www/xxxx.xxxx.xxx/"
<Directory "/var/www/xxxx.xxxx.xxx">
Options Indexes FollowSymLinks
require all granted
AllowOverride All
</Directory>
Include /usr/local/etc/apache24/sites/deflate.conf
Include /usr/local/etc/apache24/sites/domain2-ssl.conf
</VirtualHost>

<VirtualHost *:80>
ServerName www.doman2.com
ServerAlias domain2.com www.domain2.us domain2.us
Redirect permanent / https://www.domain2.com/
</VirtualHost>
<VirtualHost *:443>
ServerName domain2.com
ServerAlias www.domain2.com
ServerAdmin sup...@domain2.com
DocumentRoot "/var/www/www.domain2.com/"
<Directory "/var/www/www.domain2.com">
Options Indexes FollowSymLinks
require all granted
AllowOverride All
</Directory>
Include /usr/local/etc/apache24/sites/deflate.conf
Include /usr/local/etc/apache24/sites/domain2-ssl.conf
</VirtualHost>

Is there any reason that domain1.com and domain2.com (vhost1 and vhost2) works but support.domain1.com (vhost 3)doesn't work. I am absolutely at a loss?

--
This e-mail and any attachments may contain information that is
confidential and/or privileged and prohibited from disclosure or
unauthorized use under applicable law. If you are not the intended
recipient, you are hereby notified that any disclosure, copying or
distribution or taking of action in reliance upon the contents of this
transmission is strictly prohibited. If you have received
this e-mail in
error, you are instructed to notify the sender by reply e-mail and delete
it to the fullest extent possible once you
have notified the sender of the
error.

The Doctor

unread,

Mar 2, 2021, 10:01:29 AM3/2/21

to

In article <4eca304a-ca88-4e96...@googlegroups.com>,

I should probably write a blog entry on this.

I used to use Apache but moved over to nginx.

However, the way I did it was to use

the httpd-ssl.conf for port 443 and https-vhosts.conf for port 80.

How did you set up the let's encrypt?

>--
>This e-mail and any attachments may contain information that is
>confidential and/or privileged and prohibited from disclosure or
>unauthorized use under applicable law. If you are not the intended
>recipient, you are hereby notified that any disclosure, copying or
>distribution or taking of action in reliance upon the contents of this
>transmission is strictly prohibited. If you have received
>this e-mail in
>error, you are instructed to notify the sender by reply e-mail and delete
>it to the fullest extent possible once you
>have notified the sender of the
>error.

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
30 years on the Internet http://bit.ly/3uxzSzT

Jeff Long

unread,

Mar 2, 2021, 10:24:15 AM3/2/21

to

I don't see anything in your configuration that would match
support.domain1.com

Jeff

Tamer Ziady

unread,

Mar 2, 2021, 12:45:04 PM3/2/21

to

Set up let's encrypt using the ACME CLI client & remote DNS authorization w/ Godaddy via their API. Works very well. Using Crontab to manage renewals. Usually very effortless except for the throw up here and there. I am pretty much using all 443 at this point and may even block 80 all together but likely not a good idea.

Tamer Ziady

unread,

Mar 2, 2021, 12:50:13 PM3/2/21

to

There isn't a support.domain1.com. At this point only 3 vhosts:

1. domain1.com (alias www.domain1.com)
2. domain2.com (alias www.domain2.com and some others for .us and stuff)
3. support.domain2.com (a subhost under domain2)

so, 2 & 3 are related. And 1 doesn't have any sub hosts. Pretty much will be *domain1.com once I move further fixing this issue.

Hope that makes sense?

Cheers,
T

Tamer Ziady

unread,

Mar 2, 2021, 12:53:14 PM3/2/21

to

On an absolute side note and not to soil this mailing list with another software; what made you move to NGINX?

Cheers,
T

The Doctor

unread,

Mar 2, 2021, 6:18:07 PM3/2/21

to

In article <cef501a5-f8f1-479f...@googlegroups.com>,

Tamer Ziady <ne...@in-design.com> wrote:
>
>
>On an absolute side note and not to soil this mailing list with another
>software; what made you move to NGINX?
>
>Cheers,
>T
>

Performance and less admin overhead!

>--
>This e-mail and any attachments may contain information that is
>confidential and/or privileged and prohibited from disclosure or
>unauthorized use under applicable law. If you are not the intended
>recipient, you are hereby notified that any disclosure, copying or
>distribution or taking of action in reliance upon the contents of this
>transmission is strictly prohibited. If you have received
>this e-mail in
>error, you are instructed to notify the sender by reply e-mail and delete
>it to the fullest extent possible once you
>have notified the sender of the
>error.

The Doctor

unread,

Mar 2, 2021, 6:19:41 PM3/2/21

to

In article <86e5156f-8b4b-417a...@googlegroups.com>,

Just redirect your prot 80 traffic to port 443.

>--
>This e-mail and any attachments may contain information that is
>confidential and/or privileged and prohibited from disclosure or
>unauthorized use under applicable law. If you are not the intended
>recipient, you are hereby notified that any disclosure, copying or
>distribution or taking of action in reliance upon the contents of this
>transmission is strictly prohibited. If you have received
>this e-mail in
>error, you are instructed to notify the sender by reply e-mail and delete
>it to the fullest extent possible once you
>have notified the sender of the
>error.

Tamer Ziady

unread,

Mar 3, 2021, 8:41:25 AM3/3/21

unread,

Mar 5, 2021, 8:01:30 PM3/5/21

to

Probably a more elegant solution.

Maybe I will move it back.

Tamer Ziady

unread,

Mar 7, 2021, 5:24:17 PM3/7/21

to

Anyway, I am still stuck and no matter what I try I cannot get the 3rd VHOST working :(...

Cheers,

Jeff Long

unread,

Mar 8, 2021, 11:19:08 AM3/8/21

to

On 3/5/21 3:28 PM, Tamer Ziady wrote:
> # apachectl -S
> VirtualHost configuration:
> *:80 is a NameVirtualHost
> default server domain1.com (/usr/local/etc/apache24/sites.enabled/002-domain1.com.conf:1)
> port 80 namevhost domain1.com (/usr/local/etc/apache24/sites.enabled/002-domain1.com.conf:1)
> port 80 namevhost support.domain2.com (/usr/local/etc/apache24/sites.enabled/004-support.domain2.com.conf:1)
> alias support.domain2.us
> port 80 namevhost www.domain2.com (/usr/local/etc/apache24/sites.enabled/006-domain2.com.conf:1)
> alias domain2.com
> alias www.domain2.com
> alias domain2.us
> *:443 is a NameVirtualHost
> default server domain1.com (/usr/local/etc/apache24/sites.enabled/002-domain1.com.conf:5)
> port 443 namevhost domain1.com (/usr/local/etc/apache24/sites.enabled/domain1.com.conf:5)
> alias www.domain1.com
> port 443 namevhost support.domain2.com (/usr/local/etc/apache24/sites.enabled/004-support.domain2.com.conf:6)
> alias support.domain2.us
> port 443 namevhost domain2.com (/usr/local/etc/apache24/sites.enabled/006-domain2.com.conf:6)
> alias www.domain2.com
> ServerRoot: "/usr/local"
> Main DocumentRoot: "/usr/local/www/apache24/data"

>

> I really do not see any issues, except for the Main DocumentRoot is incorrect since I am actually using /var/www/

I think I would agree that your config there looks fine. Have you tried
using your browser's developer tools to see if you're somehow getting
redirected to domain2.com?

Jeff

Tamer Ziady

unread,

Mar 8, 2021, 4:37:09 PM3/8/21

to

Thanks for the suggestion. I looked via Dev Tools and saw no redirection.

I did some additional testing.

The Let's Encrypt cert that I was using was a *.domain.com

So, just to make sure that was not somehow doing anything, I got individual certs for each www and support

However, that did not help.

In testing a whole bunch of things; I discovered a rather odd behavior.

These sites are Wordpress sites.

If I go to https://support.domain2.com it just redirects to https://www.domain2.com

However, if I go to https://support.domain2.com/info.php (or any sub wp-admin, whatever) it works.

I am not sure what would cause this behavior at all. However, I am going to post this with Wordpress now; as I do not think the issue is Apache and SSL.

If anyone has any idea why this kind of behavior would occur with WP, please let me know.

And thank you everyone for your help and responses with this issue.

Cheers,
T

Eli the Bearded

unread,

Mar 8, 2021, 7:36:19 PM3/8/21

to

In comp.infosystems.www.servers.unix, Tamer Ziady <ne...@in-design.com> wrote:
> In testing a whole bunch of things; I discovered a rather odd behavior.
>
> These sites are Wordpress sites.
>
> If I go to https://support.domain2.com it just redirects to https://www.domain2.com

...

> If anyone has any idea why this kind of behavior would occur with WP, please let
> me know.

Wordpress, when invoked, always wants to redirect you to the FQDN the
blog is configured for. If you go to random specific files you may be
able to view them without invoking Wordpress.

Look for the "X-Redirect-By: WordPress" header:

curl --dump-header tmp.file https://support.domain2.com/ > /dev/null

Elijah
------
has fought with WP over this before

Message has been deleted

Tamer Ziady

unread,

Mar 9, 2021, 10:28:01 AM3/9/21

to

Thanks for the suggestion. I believe the issue is still SSL related. As this is what I get when I try using CURL:

# curl --dump-header tmp.file https://support.domain2.com/ > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

and when I use --insecure

It returns

# more tmp.file
HTTP/1.1 404 Not Found
Date: Tue, 09 Mar 2021 14:52:40 GMT
Server: Apache/2.4.46 (FreeBSD) OpenSSL/1.1.1h-freebsd
Content-Length: 196
Content-Type: text/html; charset=iso-8859-1

However, I am still able to access info.php....

Checking if maybe .htaccess is the culprit.

So at a loss here.