Connection problems with two domain names and nginx

Hi guys,

I am not sure if my question fits in here, please let me know, if it doesn’t. It’s actually rather an nginx configuration problem. :slight_smile:

The story goes like this: I have a website with two (sub)domains names, an old one (photon.serverpit.com) and a new one (tpiq.lmu.serverpit.com), and would like to redirect all requests targeting both domains and both http and https to the new domain using https, that is, https://tpiq.lmu.serverpit.com.

I had an old messy nginx configuration for just one domain name and http only. Then certbot added https related lines. Then I tried to at least forward everything to https. This is how it looks like:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;

    # Add index.php to the list if you are using PHP
    index index.html index.php index.htm index.nginx-debian.html;

    server_name photon.serverpit.com tpiq.lmu.serverpit.com;
        auth_basic "Restricted"; 
        auth_basic_user_file /etc/nginx/.htpasswd; 

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }

    # pass PHP scripts to FastCGI server

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;

        # With php-fpm (or other unix sockets):
        fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
        # With php-cgi (or other tcp sockets):
    #    fastcgi_pass 127.0.0.1:9000;
    }

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one

    location ~ /\.ht {
        deny all;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/tpiq.lmu.serverpit.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/tpiq.lmu.serverpit.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    # redirect http to https (and new domain)

    if ($scheme = http) {
        return 301 https://tpiq.lmu.serverpit.com$request_uri;
    }
}

This works partially, that is, if the URL uses http, it does redirect. But, obviously, if we access the old domain with https, the redirect doesn’t fire.

Removing the if clause altogether doesn’t work, because then it redirects in an endless loop. So I asked on a forums and people told me that ifs are evil in nginx and proposed a different approach using several server blocks, which I tried to implement and looks like this:

#redirect http -> https
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;

    return 301 "https://tpiq.lmu.serverpit.com${request_uri}";
}

#redirect https photon.serverpit.com -> tpiq.lmu.serverpit.com
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name photon.serverpit.com;

    ssl_certificate /etc/letsencrypt/live/tpiq.lmu.serverpit.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/tpiq.lmu.serverpit.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    return 301 "https://tpiq.lmu.serverpit.com${request_uri}";
}

#config for https tpiq.lmu.serverpit.com
server {
    server_name tpiq.lmu.serverpit.com;

    root /var/www/html;
 
    # Add index.php to the list if you are using PHP
    index index.html index.php index.htm index.nginx-debian.html;

    server_name photon.serverpit.com tpiq.lmu.serverpit.com;
        auth_basic "Restricted"; 
        auth_basic_user_file /etc/nginx/.htpasswd; 
   
    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }

    # pass PHP scripts to FastCGI server
 
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
 
        # With php-fpm (or other unix sockets):
        fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
        # With php-cgi (or other tcp sockets):
    #    fastcgi_pass 127.0.0.1:9000;
    }

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
 
    location ~ /\.ht {
        deny all;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/tpiq.lmu.serverpit.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/tpiq.lmu.serverpit.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

However, for some reason, with this configuration the browser reports that it cannot resolve the URL at all, as if such an URL didn’t exist on the net. So I am stuck at this point… I have to admit that I don’t have any profound knowledge about nginx configuration but rather try to make things work by digging up stackexchange answers, howtos etc. I’m not dealing with server configuration professionally but am now in a situation where I have to get it up and running. But nevertheless I would appreciate any reading which would help understand what is going on!

Thanks for any input!

My domain is: photon.serverpit.com, tpiq.lmu.serverpit.com

I ran this command: sudo certbot --nginx

It produced this output: https://pastebin.com/Gzna3aQg

My web server is (include version): nginx 1.10.3

The operating system my web server runs on is (include version): Raspbian GNU/Linux 9.11 (stretch)

My hosting provider, if applicable, is: none

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.28.0

remove this line.

also: there is no A record on the domain you are redirecting to. (nor on the original one) –edit: there is one now, it looks like your website works (or at least asks for username and password)

1 Like

Thanks a ton, such a stupid copy&paste error! :smiley: It works perfectly now!

Yeah, there are lecture notes on this site (not mine, and the lecturer doesn’t want them to be publicly accessible).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.