Why is https not being enforced?

I’ve never had an issue before using the SSL applied to the domain, using a custom domain name. My DNS is being managed elsewhere.

According to the SSL certificate check in Netlify’s control panel, the Let’s Encrypt has been successfully applied. However, It’s not redirecting to https. For example, if user types in mydomain.com, I’d it expect https not http. Or if user types in http://mydomain.com, I’d expect it to redirect to https://mydomain.com. Is there something else I need to set within Netlify, or some other record I need to add to my registrar?

What is the domain you are having issues with?

The domain is katinawilson.com

HTTPS works for me on all browsers tested. e.g.

HTTPS does work, but as I mentioned the problem is when visiting http://katinawilson.com or just katinawilson.com – it doesn’t redirect to https.
BTW, I’ve cleared my browser cache, and have tried in multiple browsers.

I typed katinawilson.com into the browser address bar (implying http://) and was redirected (again, on all browsers tested.)

This is also evident when using cURL

% curl -I http://katinawilson.com
HTTP/1.1 301 Moved Permanently
Location: https://katinawilson.com/
1 Like

I’ll take your word for it, but I’m not the 301 redirect:

curl -I http://katinawilson.com
HTTP/1.1 200 OK
Age: 9959
Cache-Control: public, max-age=0, must-revalidate
Content-Length: 743
Content-Type: text/html; charset=UTF-8
Date: Thu, 16 Mar 2023 18:24:44 GMT
Etag: "372ce6f54570c50c455e970da621e806"
Server: Netlify

I flushed DNS cache on my system, too.

Hi, @djmtype. That is quite odd above. There is no x-nf-request-id header which is unusual. Also, I would recommend not testing with the curl option -I.

The -I option uses the HEAD method. You shouldn’t test the CDN using HEAD if you want to see how it will behave during real world use. It should be tested using GET (and using compression with the --compressed option) to see the real CDN behavior.

For example, these are the curl options I use in my own testing:

$ curl --compressed -svo /dev/null http://katinawilson.com/  2>&1 | egrep '^(<|>)'
> GET / HTTP/1.1
> Host: katinawilson.com
> User-Agent: curl/7.86.0
> Accept: */*
> Accept-Encoding: deflate, gzip
>
< HTTP/1.1 301 Moved Permanently
< Location: https://katinawilson.com/
< Server: Netlify
< X-Nf-Request-Id: 01GVPCH3GBVF42SPAYMW5WX727
< Date: Thu, 16 Mar 2023 23:36:51 GMT
< Content-Length: 40
< Content-Type: text/plain; charset=utf-8
<

That is using a GET method above. Using that I see both the header X-Nf-Request-Id: 01GVPCH3GBVF42SPAYMW5WX727 and I also see the redirect to HTTPS. That x-nf-request-id header is a key piece of debugging information as it is unique to a single HTTP response and allows our support team to examine the path the request takes through our infrastructure.

@jasiqli, would you please try the command above and then share the output here? Note, that command above is using Unix/Linux syntax (MacOS is a Unix variant) so it may need to be modified if you are using Windows.

Using the same command as you did @luke yields the same result

 % curl --compressed -svo /dev/null http://katinawilson.com/  2>&1 | egrep '^(<|>)'
> GET / HTTP/1.1
> Host: katinawilson.com
> User-Agent: curl/7.86.0
> Accept: */*
> Accept-Encoding: deflate, gzip
>
< HTTP/1.1 301 Moved Permanently
< Location: https://katinawilson.com/
< Server: Netlify
< X-Nf-Request-Id: 01GVPDWPWFJ65BD7GEAHEYF66W
< Date: Fri, 17 Mar 2023 00:00:41 GMT
< Content-Length: 40
< Content-Type: text/plain; charset=utf-8
<

Thanks @jasiqli and @luke. It’s finally redirecting here. I don’t know if an SSL certificate takes time to provision properly, and that was the reason?

hi @djmtype glad to hear it is working for you. Excellent debugging skills @jasiqli you were incredibly helpful. SSL should be virtually immediate upon creation of a Netlify subdomain . SSL provisioning delays should only occur with custom domains due to DNS propagation (usually).

2 Likes