Can't access dashboard after SSL install

Are you terminating SSL at the Nginx layer or at the Apache layer? A Gist or Pastebin of your exact Nginx configs, stripped of sensitive info, would be very helpful.

I am terminating at Nginx. configs are below. There is no “http” before my server names “www.subdomain.domain.com”, this forum must be adding them.

Nginx

server {
listen 80;
server_name subdomain.domain.com https://www.subdomain.domain.com;
access_log /var/log/nginx/subdomain.domain.log;
rewrite ^ https://$server_name$request_uri; # enforce https
}
server {
listen 443;
ssl on;
server_name subdomain.domain.com https://www.subdomain.domain.com;
ssl_certificate /etc/ssl/certs/ssl-bundle.crt;
ssl_certificate_key /etc/ssl/myserver.key;

access_log /var/log/nginx/subdomain.domain.log;

location / {

client_max_body_size 20M;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded_Proto https;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
set $portNum 8083;

proxy_pass https://127.0.0.1:$portNum;
}

}

Apache

<VirtualHost *:8083>

DocumentRoot /my/path/to/wordpress/

Alias /openatrium/ /my/path/to/wordpress/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>

<Directory my/path/to/wordpress/>
Options +FollowSymLinks
AllowOverride All
order allow,deny
allow from all
</Directory>

</VirtualHost>

I’m pretty sure that should be X-Forwarded-Proto with two dashes in the nginx config, not with a single underscore.

Doubt that is your problem, but still.

Do you see any of the hits ever make it to the Apache logs?

Also, skip the plugin entirely. The WordPress admin can do SSL all by itself, no plugin needed. Reduce complications when trying to sort out the issues.

If you need the plugin later, then you add it later. But for just trying to get it to work, leave it out of the equation.

Also what Otto said there — you won’t ever force $_SERVER[‘https’] to ‘on’ because it’s matching against a header that’s not being sent.

Actually, in his case, forcing $_SERVER[‘HTTPS’]=’on’ is exactly what he wants to do. That code he has in the wp-config.php is correct.

See https://core.trac.www.ads-software.com/ticket/20567

The gist of it is that Apache is running HTTP. It’s serving to nginx, which reserves it over HTTPS (aka, reverse-proxy). Because Apache is not in https mode, it’s telling PHP so, and $_SERVER[‘HTTPS’] isn’t set. But he actually *wants* it to be set, because the end result is indeed an HTTPS page.

So, by detecting the HTTP_X_FORWARDED_PROTO and then forcing the HTTPS to be on, then everything in PHP land, WordPress included, acts as if it’s serving to an end-goal of https. This is the desired outcome.

Right, I’m saying he’s matching against an invalid header in his if() check, not that he doesn’t want to force it.

Oh, right. ??

I don’t know exactly how nginx will act with that underscore instead of the dash, actually. Might work. So, not sure if that’s the answer here.

Otto:
If he hasn’t enabled underscores in headers, Nginx will flag the header as invalid and ignore.

https://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers

I changed the underscore in my Nginx config to a ‘-‘. Still no joy. Here is my apache log.

[Wed Dec 10 11:02:35 2014] [info] removed PID file /var/run/apache2.pid (pid=4400)
[Wed Dec 10 11:02:35 2014] [notice] caught SIGTERM, shutting down
[Wed Dec 10 11:02:36 2014] [info] Init: Seeding PRNG with 656 bytes of entropy
[Wed Dec 10 11:02:36 2014] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Wed Dec 10 11:02:36 2014] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Wed Dec 10 11:02:36 2014] [info] Init: Initializing (virtual) servers for SSL
[Wed Dec 10 11:02:36 2014] [info] mod_ssl/2.2.22 compiled against Server: Apache/2.2.22, Library: OpenSSL/1.0.1
[Wed Dec 10 11:02:36 2014] [warn] module deflate_module is already loaded, skipping
PHP Warning: Module ‘apc’ already loaded in Unknown on line 0
[Wed Dec 10 11:02:36 2014] [info] Init: Seeding PRNG with 656 bytes of entropy
[Wed Dec 10 11:02:37 2014] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Wed Dec 10 11:02:37 2014] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Wed Dec 10 11:02:37 2014] [debug] ssl_scache_shmcb.c(253): shmcb_init allocated 512000 bytes of shared memory
[Wed Dec 10 11:02:37 2014] [debug] ssl_scache_shmcb.c(272): for 511920 bytes (512000 including header), recommending 32 subcaches, 133 indexes each
[Wed Dec 10 11:02:37 2014] [debug] ssl_scache_shmcb.c(306): shmcb_init_memory choices follow
[Wed Dec 10 11:02:37 2014] [debug] ssl_scache_shmcb.c(308): subcache_num = 32
[Wed Dec 10 11:02:37 2014] [debug] ssl_scache_shmcb.c(310): subcache_size = 15992
[Wed Dec 10 11:02:37 2014] [debug] ssl_scache_shmcb.c(312): subcache_data_offset = 3208
[Wed Dec 10 11:02:37 2014] [debug] ssl_scache_shmcb.c(314): subcache_data_size = 12784
[Wed Dec 10 11:02:37 2014] [debug] ssl_scache_shmcb.c(316): index_num = 133
[Wed Dec 10 11:02:37 2014] [info] Shared memory session cache initialised
[Wed Dec 10 11:02:37 2014] [info] Init: Initializing (virtual) servers for SSL
[Wed Dec 10 11:02:37 2014] [info] mod_ssl/2.2.22 compiled against Server: Apache/2.2.22, Library: OpenSSL/1.0.1
[Wed Dec 10 11:02:37 2014] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.15 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/1.0.1 configured — resuming normal operations
[Wed Dec 10 11:02:37 2014] [info] Server built: Jul 22 2014 14:35:25
[Wed Dec 10 11:02:37 2014] [debug] prefork.c(1023): AcceptMutex: sysvsem (default: sysvsem)
[Wed Dec 10 11:02:43 2014] [debug] mod_headers.c(756): headers: ap_headers_output_filter()
[Wed Dec 10 11:02:43 2014] [debug] mod_deflate.c(700): [client 127.0.0.1] Zlib: Compressed 0 to 2 : URL /index.php
[Wed Dec 10 11:02:43 2014] [debug] mod_headers.c(756): headers: ap_headers_output_filter()
[Wed Dec 10 11:02:43 2014] [debug] mod_deflate.c(700): [client 127.0.0.1] Zlib: Compressed 4362 to 1534 : URL /wp-login.php
[Wed Dec 10 11:02:43 2014] [debug] mod_headers.c(756): headers: ap_headers_output_filter()

You can view the login for my page at ap.bpwgroup.com. It is secured now but the CSS is broken and it doesn’t have the full green SSL lock in the address bar. This is with the settings I posted in my first post but with the X-FORWARDED-PROTO instead of an underscore.

Wrong apache log file. What about the access.log? Does it show the hits coming from the nginx instance?

Also, I’m not sure why you have mod_ssl working on the Apache instance if you’re using an nginx reverse-proxy to provide SSL support.

Also, your login screen still has references to http URLs in it. Are you sure you have FORCE_SSL_LOGIN and FORCE_SSL_ADMIN turned on properly, as well as having that if ($_SERVER line? This all needs to happen at the top of the file, where the other defines are.

Well holy crap! I didn’t have the FORCE_SSL_LOGIN and FORCE_SSL_ADMIN as well as the if ($_SERVER line at the top of the config.php file. It was near the bottom. That appears to have fixed it from what I can tell so far!

Thank you so much for the help!!

One little thing, On a lot of my pages I’m still getting the grey padlock with orange triangle in my address bar that Google defines as meaning

Your connection to the site is encrypted, but Google Chrome has detected mixed content on the page.

Any idea how to correct that?

Ahh, yeah, that would be it. Adding defines to the bottom of the file doesn’t really do much, because all the code that reads the defines happens before that.

Everything you put into a wp-config.php file needs to be above the line that reads:
/* That's all, stop editing! Happy blogging. */

As for the mixed content, your login logo is using an http URL. Switch it to an https one. Same for any other http URLs you have in the site.

Thank you very much! I’ll start working on that!