Join Log in
Score:1
Jetto Martínez avatar Server

Setted Apache subdomain redirect to another subdomain

fr flag
Jetto Martínez

I'm trying to set up two subdomains, for a and b in domain.com. I use two .conf files, which look pretty much the same with according changes to ServerName and ProxyPass:

<VirtualHost *:80>
        ServerName a.domain.com #This was added as a try for a fix. 
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>

        ServerName a.domain.com
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/a

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        #SSL stuff

        #Proxies

        ProxyPass        /        https://a.domain.com:8444/
        ProxyPassReverse /        https://a.domain.com:8444/
        ProxyPass        /a/      https://a.domain.com:8444/
        ProxyPassReverse /a/      https://a.domain.com:8444/
        ProxyPass        /b/      https://b.domain.com:8445/
        ProxyPassReverse /b/      https://b.domain.com:8445/

</VirtualHost>

This is being done my test environment, replicating something similar to what is currently in production. In /etc/hosts, I added a.domain.com and b.domain.com to 127.0.0.1. The DNS in production has records for what a.domain.com and b.domain.com are, which is the same IP (I also did this in the machine from which I'm testing this).

Also note that I'm not serving any content from their root directories. I added that trying to fix the issue stated in the title. There is a simple html in both directories though.

What is the actual problem?

Simply, when trying a.domain.com, the result is the webapp from localhost:8444, as expected. When trying b.domain.com, the result is also localhost:8444, instead of localhost:8445. Both a.conf and b.conf are enabled, and if I disable a.conf, then I'm correclty getting localhost:8445. If I also try like a.domain.com/b, the redirect resolves back to a.domain.com.

I've read several questions and tutorials, and most of them either have something working as in my configuration or add NameVirtualHost, which I understand is not needed for my version of Apache. I also added a ServerName in port 80 as I thought that perhaps the request for b was being matched by a.conf as they are the same IP, but that didn't worked either.

What am I missing here? Is it something with mod_proxy I seem to be ignoring? If possible, I'd like to keep one file per webapp. Thanks!

This is on Ubuntu 18.04.2, Apache 2.4 (mod_proxy and mod_ssl), Tomcat 9. Any other info you'd like, I'll try my best to deliver.

UPDATE

Tried with this configuration too. Same undesired result.

<VirtualHost *:80>
        ServerAlias a.domain.com
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>

        ServerName a.domain.com
        ServerAdmin webmaster@localhost

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        #SSL stuff

        #Proxies

        Redirect /b https://b.domain.com

        <Location />
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

        <Location /a>
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

</VirtualHost>

UPDATE

Ok, I just found something very annoying. If I enter with my browser to either a.domain.com or b.domain.com, they both resolve to a.domain.com. That is the problem I described originally. BUT if try https://a.domain.com or https://b.domain.com, both resolve to the right server: a to 8444 and b to 8445.

As this is very frustrating, I'll take a brake and analize this in a while.

UPDATE

After a long brake, I tried some other random tweaks just to see what happened and yet again nothing worked as expected, except when using HTTPS. I installed Postman to see what was being send in the request and found out that in Postman, both HTTP and HTTPS use the Host correctly. Even better/worse: The actual response shows the different welcome pages for a.domain.com and b.domain.com, meaning that my configurations are working properly, when I use Postman.

I think all this ordeal might just be a cache problem, but my testing browser of choice (Firefox dev ed) is set to not cache stuff. I will check the responses with curl and with my other browsers.

184
1 + 2
kz flag
MrWhite
You mention _caching_ ... bear in mind that 301 directives are cached persistently (by the browser and possibly intermediary caches). If you previously omitted the `ServerName a.domain.com` directive in the vHost:80 (and corresponding directive for `b.domain.com`) then the redirect from `http://b.domain.com/` to `https://a.domain.com` might have been cached (depends on the order in which your config files are included). So yes, that directive is actually _essential_.
1
Reply
Jetto Martínez avatar
fr flag
Jetto Martínez
Yes, your comment came at the exact time I posted the answer. It was indeed the cache. I had my browser set up to not cache anything, but it was caching. I'm not sure why this configuration was reset. With this fixed I will still look into this. Thanks!
1
Reply
Score:1
Jetto Martínez avatar Server
fr flag
Jetto Martínez

Culprit: The cache.

At some point, my browser's configuration changed (Perhaps an update?) and I had over 3GB worth of cache, including the test sites I was trying to set up as subdomains. Yikes.

After clearing the cache prompted an alert about my self-signed certificate when hitting my URLs, as expected. After accepting the risks, I was redirected to the proper sites. This by using b.domain.com without adding the protocol.

To make sure this was working, I tested in all my other 7 browsers (Gotta make sure) and curl with and without the protocol and the results were the desired as well.

In the end the config was ok. I'll post it here in case you need An Apache server proxying to specific Tomcat instances by subdomain, using proxy_mod that also redirects immediately from port 80 to port 433.

<VirtualHost *:80>
        ServerName a.domain.com
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>
        
        ServerName a.domain.com
        ServerAdmin [email protected]

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        #SSL stuff

        SSLEngine On
        SSLCertificateFile /etc/ssl/certs/DONT_USE_SELF_SIGNED.pem
        SSLCertificateKeyFile /etc/ssl/private/CERTS_IN_PRODUCTIve.key
        SSLVerifyClient none

        #Proxies
        ProxyRequests Off
        SSLProxyEngine on
        SSLProxyVerify none
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
        SSLProxyCheckPeerExpire off

        #Redirections
        Redirect /b https://b.domain.com

        <Location />
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

        <Location /a>
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

</VirtualHost>

Please take into consideration that the settings for SSL Proxy and SSL are for Self-signed certs. Please read the relevant documentation for each if you implement this for productive environments. Also note that this is the configuration file for a.domain.com. The equivalent for b.domain.com is exactly the same, with the appropiate ServerName, ServerAlias, redirects, Location and port of localhost.

0 + 3
kz flag
MrWhite
Minor point, but you don't need `ServerName` _and_ `ServerAlias` if they are referring to the same _hostname_.
0
Reply
Jetto Martínez avatar
fr flag
Jetto Martínez
Noted. ServerName is the one I should keep, right?
1
Reply
kz flag
MrWhite
Yes, that's right.
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.