hndev

None, it’s just a base installation with ignite theme…

I found out that the file permissions were 664 and 775 and changed them to suggested 644 and 755 but it didn’t change anything either…

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

I always do it -R and did it again once more to be sure, but still the result is exactly the same…

At least in other of my websites the owner is the user that runs php-fpm ie apache

It’s the apache user which should be the right choice for centos based installation

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/…

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, 11 months ago by hndev.

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…

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.

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)

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).

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…

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… ??

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).