It appears that the issue was in fact on the server and the way the load balancer was handling the https.
Comment from server company:
What I saw when looking at this is that the header X-Forwarded-Proto is showing "http" regardless of whether the request uses http or https. I am not sure why that is, but I assume it has to do with the levels of proxying from Nginx --> Load Balancer --> Server. I'm guessing that X-Forwarded-Proto is already set when the load balancer gets the request, so it doesn't update it to https. Or perhaps you are terminating SSL at Nginx, and sending the request to the load balancer via http?
At any rate, we normally use a statement like this in the Apache config:
SetEnvIf X-Forwarded-Proto https HTTPS=on
This means that if the original request was https, then set an Apache environment variable called "HTTPS" so that Apache and PHP will know the request was over https. For some reason, though, X-Forwarded-Proto is always "http" and never "https" in your configuration. Since you are setting the WordPress URL to always be https, I have just set this Apache environment variable unconditionally via this statement:
SetEnv HTTPS on
That gives the proper result, a WordPress login screen. I think it would be good to have the load balancer enforce https, but I can't enable that without the private key.
This appears to now be fixed.
This image is hidden for guests.
Please log in or register to see it.
Wicko Design is a multi-disciplined creative agency based in the South East of England. Specialising in web design & development, retail packaging and brand identity.