0

I have a root domain (https://kernl.us) that is secured via a Let's Encrypt SSL certificate. This works fine, but when I try to go to a new sub-domain (http://status.kernl.us) Chrome redirects me to HTTPS. The sub-domain is a CNAME record that points to a Pingdom status page. I have no control over it's HTTP/S status.

If I open Firefox there is no HTTPS redirect. I suspect that this has to do with the Let's Encrypt SSL cert and some stored behavior in Chrome, but I'm not sure where to start looking.

I found this: https://community.letsencrypt.org/t/every-subdomain-is-redirecting-to-https-even-non-existent-ones/18095 which seems to be my problem, but my Nginx config isn't setting any HSTS settings.

Any ideas?

Nginx Config

server {
    listen 443;
    server_name kernl.us;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/kernl.us/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/kernl.us/privkey.pem; # managed by Certbot

    ssl_session_timeout 30m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS:!DH;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:30m;

    location /static/ {
        autoindex on;
        expires 7d;
        gzip on;
        gzip_vary on;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private auth;
        gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
        gzip_disable "MSIE [1-6]\.";
        root /var/www/kernl/kernl/public/;
    }

    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        add_header X-Nginx-Server 'nginx1';
        add_header X-Upstream $upstream_addr;
    }
}
  • Try resetting chrome. There may be stale cache or HSTS data. – Richard Smith Jan 8 at 16:45
  • This seems to work, but I'm concerned about users who don't know that they need to do this. Is there any way to fix this for everyone from my end? Nginx headers or something like that? – Jack Slingerland Jan 8 at 18:43
  • What was the original cause of the problem? – Richard Smith Jan 8 at 19:39
  • I honestly don't know. Maybe Nginx being mis-configured before I started using Let's Encrypt? – Jack Slingerland Jan 8 at 22:04
0

If you look here: https://hstspreload.org/?domain=kernl.us or here: https://www.ssllabs.com/ssltest/analyze.html?d=kernl.us&hideResults=on you can see HATS is preloaded (i.e. hardcoded) into the Chrome code.

You normally need to be publishing HSTS headers for that to happen and they may remove it from the code since this domain is no longer doing it.did you do this? Or a previous owner or administrator of this domain?

So basically it’s HTTPS only for this domain and sub domains going forward I’m afraid. At least until Chrome removes this code and all your users stop using any versions of Chrome with that code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.