This site can’t provide a secure connection <- Only on Google Chrome or without www

Ok boys ‘n’ girls, I’ve been wracking my brain all day trying to solve this issue, and I gotta say it’s definitely a bizarre one.

Background:
NGINX server running on ubuntu 16,
ufw enabling OpsenSSH, 80, 443 (and v6 for all 3)
I ran certbot -nginx to get my certificates (like I have done numerous times on my other servers).
SSL tested successful (test results below)
https://www.ssllabs.com/ssltest/analyze.html?d=hyden.ca&fbclid=IwAR17uXxVpGEDyRNRrsHORvmv3cR8hgAqtX1HvFVpQFEhSwYGRe0BBmRDNdI#httpRequests

Now, the issue: Google chrome tells me that ‘The site can’t provide a secure connection’, I’ve tried clearing my cache and such, no luck. The WEIRD part though? If I go on any other browser, or even incognition mode, hyden.ca will fail, but www.hyden.ca will work, it will do the redirect to hyden.ca, and then any future attempts to load hyden.ca will also work (until I close and reopen the browser).

This has led me to believe that something is wrong with my sites-enabled script, so here it is:

HTTP — redirect all traffic to HTTPS

server {
listen 80;
listen [::]:80 default_server ipv6only=on;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name www.hyden.ca;
ssl_certificate /etc/letsencrypt/live/hyden.ca/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/hyden.ca/privkey.pem; # managed by Certbot
return 301 https://hyden.ca$request_uri;
}

HTTPS — proxy all requests to the Node app

server {
# Enable HTTP/2
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name hyden.ca;

# Use the Let’s Encrypt certificates
ssl_certificate /etc/letsencrypt/live/hyden.ca/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/hyden.ca/privkey.pem; # managed by Certbot

#SSL configuration
include snippets/ssl-params.conf;

location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass http://localhost:3000/;
    proxy_ssl_session_reuse off;
    proxy_set_header Host $http_host;
    proxy_cache_bypass $http_upgrade;
    proxy_redirect off;
}

}

and this is my snippets/ssl-params

See https://cipherli.st/ for details on this configuration

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH”;
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security “max-age=63072000; includeSubDomains; preload”;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

Add our strong Diffie-Hellman group

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Does anyone see an issue that I am just clearly missing?? I feel like my SSL configuration might have something wrong with it but I can’t for the life of me figure it out.

Cheers,
Hyden

e: Seems like you’ve fixed it?

I’d also suggest using https://ssl-config.mozilla.org rather than your current tunings, it seems like an odd mix of settings. (But I don’t think that’s directly causing the failure).

1 Like

Hey!

Thanks for the fast reply.
I threw the include into the first server block, and nothing changed at first.
I then was changing it all based on the link you sent me (extremely useful btw), but before I saved my changes I came back to this page and saw that you said I fixed it. So, unbeknownst to me, your suggestion of the include fixed my issue (literally like 6 hours of head banging…)

1 Like

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