WordPress redirects to http, though settings for https

Hi, hndev, & welcome. Firstly, unfortunately, you can’t do https from an IP. An SSL certificate is all about a domain name & verifying its owner, etc, prior to issuance of the certificate. You likely know that, but just a reminder.

If you actually want to host your server on a home network, then, unless you have a static IP for that, you’ll need to use some form of dynamic DNS. For many reasons, including security, band width usage if the site gains traction, (you could exceed your acceptable use policy), & the DNS problem just mentioned, hosting a site on a home network just really isn’t a good idea in most cases.

Your only (cheap) option, since the site is not reachable via public network, is a self-signed ssl certificate, which is pretty useless, since browsers flag it.

I think your best bet, until you decide to make the site available on a public network, is simply to instal WordPress using http: & perhaps a hosts file, if required.

Thank you abletec for the answer, but…

Actually I rounded a few corners… I have another server (proxy nginx) that handles the certificates and forwards the calls to virtual “inner servers” by http on a couple of computers at home. I also have a public fixed IP and I have half a dozen other websites with working https without any problems. I have Let’s Encrypt https working for each of them (I also got it working for this site before we found out the added wrong URL).

My work consists similar things and I think I have taken in consideration most of the risks included with self-hosting. The sites themselves are quite low-bandwith (mainly for my hobbies).

I also utilize hosts file. Normally (say a Drupal installation) is enough, if I point the IP in hosts file to the proxy nginx on the local network and everything just works.

But with this WordPress site somehow redirects https to http and that causes an infinite redirection loop as the proxy tries to redirect http to https (as it should).

Tray to look at the content of .htaccess file. It sits at the root folder of your site or/and the root of your WP installation (the last is just in case if you install WP as subfolder of your web site like /<web root folder>/<WP root subfolder>).
As you may know, in this file are stored some setting and the most important, some rewriting rules. So, it is possible a rule to exist, that rewrites https:// to https:// or vice versa. It is possible too, if this file for some reason is not writable to WP, to be impossible for WP to write inside the right settings and rules.
Just to remind, you may have more than one .htaccess file in your web site (even every folder may have such a file), so you have to find the right one – in the web root or in the WP root (the last is most probable suspect).
This way to resolve your problem is of the kind “the last thing to do”, so be careful if you decide to edit rules by hand.
The usual way is by using the regular WP tools/menus.

Good luck in hunting your bug ??

ivanmihalev, hndev is using Nginx, so in this case there won’t be a .htaccess file.

Hndev, can we please see your nginx.conf files as well as any vhost config files? Yeah–you didn’t quite tell us all that initially :).

Yes, .htacccess doesn’t mean anything to nginx ??

The nginx.conf is just plain centos default .conf which has nothing special, so I am omitting it. But here is the virtual host conf for the wordpress site:

server {
        server_name www.site.net;
        root /var/www/www.site.net;
        index index.php;
        client_max_body_size 32M;
        listen 80;

        access_log /var/log/nginx/site.net.access.log;
        error_log /var/log/nginx/site.net.error.log;

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location / {
                try_files $uri $uri/ /index.php?$args;
        }

        
        location ~ \.php$ {
          try_files $uri =404;
          fastcgi_pass unix:/run/php-fpm/www.sock;
          fastcgi_index   index.php;
          fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
          include fastcgi_params;
        }

        location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
}

And here is the respective conf file from the proxy nginx:

#
# A virtual host using mix of IP-, name-, and port-based configuration
#

	server {
    server_name  site.net www.site.net;

client_max_body_size 16M;

    location / {
        proxy_set_header Host  www.site.net;
                proxy_set_header X-Real-IP  $remote_addr;
      proxy_set_header X-Forwarded-For $remote_addr;
                proxy_pass https://site;
                }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/www.site.net/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.site.net/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

}

	server {
    if ($host = site.net) {
        return 301 https://www.site.net$request_uri;
    } # managed by Certbot

    if ($host = www.site.net) {
        return 301 https://www.site.net$request_uri;
    } # managed by Certbot

    listen       80;
    server_name  site.net www.site.net;
    return 404; # managed by Certbot

}

Hope you find the error, my eyes are already skewed after fighting with this… ??

Sorry, I just did not took in account that nginx is used.

Hey, ivanmihalev, don’t even worry about it. We need all the help we can get on here. If we all quit because of a small mistake, this place would be a ghost town. Thank you for your contributions & please please please continue. I know I speak for all the volunteers here when I say that. We all appreciate you! In addition, I’m not sure where you’re from, but those forums where people post in other languages also *really* need help badly, if your native language is other than English. We need you here in whatever capacity you feel comfortable!

hndev, I’m honestly a little confused as to how this is all playing out. I’m questioning the last 3 lines of the proxy file, but, again, since I’m not really certain how all your pieces fit together, I could well change my mind about that if I understood better. 1 thing I do when I have what appears to be a redirect problem is to run a trace command (tracert in windows) & redirect the output to a file. That way I can kind of get a picture of what is taking place w/the request on its travels. It’s helped me sort out more than 1 sticky wicket.

How is your dns routed w/this setup?

The proxy conf is modified by certbot (the program responsible for managing Let’s Encrypt certificate).

Basically it first redirects supported http (hence listen 80) requests to https and if not redirected gives 404. I think it could as well be just

listen       80;
server_name  site.net www.site.net;
return 301 https://www.site.net$request_uri;

but for some reason certbot makes it the way it does and I prefer not to interfere with its logic as it should renew the certificate automatically.

DNS routes to the external IP (which is routed in firewall to proxy nginx). Internally the hosts file points to the internal address of that proxy. As said, there are multiple other sites working just fine with that setup.

I tried to be too smart (apparently) adding an internal address DNS entry for a different host header so that even phones connected to the WLAN could view the page on https://home.site.net and made a unfortunate decision to suggest my wife to use that also for editing (hence no hosts file wouldn’t have been needed for her computer) and everything worked until I started to “mitigate” the problem where the images and stylesheets were prefixed with that https://home.site.net which wouldn’t work for anyone else given the internal un-routable address (192.168.*.*).

DNS tracing to the host works without any loops, checked bot inside (of course it’s direct because of the hosts file) and outside (just similar to the other sites I have)

If the links would have been relative, none of this would have happened… :/

I dropped the htaccess tag, as it doesn’t fit here…

To add to my former post…

I made another “Hello world”-type of “site” on the very same directory and changed only root-setting in -conf to point to this new directory – and everything works (both internally and externally) with https so in my logic the problem has to be in something WordPress does (or doesn’t).

Don’t understand anything anymore.

Now, when I reset the conf file to point back to the correct directory the site started to work with https mostly OK. I hundred per cent surely had restarted the nginx (many times) also before this, just don’t get it.

The big problem still remaining now is, that when I try to go to the /wp-admin, it still redirects to https://www.site.net/wp-admin which still causes infinite loop. All the other pages work fine.

But, it was a major step forward anyhow (though can’t understand how it happened)

Okay, now things are starting to look _really_ strange.

After whacking my head to the wall long enough, I finally decided to build another virtual server and install WordPress there.

I got it more or less working, but all the styles STILL refer to http protocol, though the database is directly after a new installation, nothing copied from the former server.

I redirected the proxy to this new server and https got up and working right from the beginning (only that the language selection screen already had the wrong protocol in style references).

I am very close to start arguing with my wife to use something else as this seems mission impossible to get working.

No, I just can’t give up.

I made some progress so far…

Adding $_SERVER[‘HTTPS’] = ‘on’; to wp_config.php finally solved wrong themes & css, now those are prefixed with https.
The scripts (like jQuery etc still keep that &/¤%&¤¤ https:// in front of them.

I actually basically even got myself sort of logged in with admin login, except that there comes 403 error (you don’t have enough privileges (or something like that, unfortunately my wife prefers Finnish translation)). The login requires the correct password or gives an error but after that it goes /wp-admin and gives that error message.

Seems that we are very close, but still not even close…

hndev, could you perhaps try doing a database search-&-replace w/something like interconnectit & change any instances of https://site.net to https://site.net & the same for https://www.site.net. It has both a GUI & CLI interface in the event the gui doesn’t work for some reason.

I have not yet had coffee. This suggestion should likely not be trusted. But if you decide to do so, then obviously please, back up your database before doing anything. O, yeah, & did I mention it’s imperative to backup your database?

Also, delete this tool when finished. It poses an incredible security risk.

I have a good friend from Finland. Cool you’re from there. Next stop–caffeine!

I run the replace and there were some changes done (and yes, did I mention, I made the backup!).

Anyhow, even after that the javascript files are still in the format https://www.site.net/&#8230;

And administrator seems not have any rights on any wp-admin pages, though admin IS logged in and can log out… Frustrating…

And yes, I did remove the replacement script from the server after the updates

• This reply was modified 3 years, 8 months ago by hndev.

Who owns your WordPress files, hndev?