# Http to https issues
**URL:** https://community.letsencrypt.org/t/http-to-https-issues/227495
**Category:** Help
**Created:** [October 18, 2024, 1:04pm UTC](https://community.letsencrypt.org/t/http-to-https-issues/227495 "2024-10-18T13:04:12Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@ATAS](https://community.letsencrypt.org/u/ATAS)
#### Post date: [October 18, 2024, 1:04pm UTC](https://community.letsencrypt.org/t/http-to-https-issues/227495/1 "2024-10-18T13:04:12Z")
My domain is:
[atasapr.org](http://atasapr.org)
My web server is (include version):
nginx 1.22.1
The operating system my web server runs on is (include version):
Rocky Linux
My hosting provider, if applicable, is:
Vultr
The version of my client is:
2.11.0
I followed along with the steps detailed on this page: [Nginx + certbot - redirect https www to https](https://community.letsencrypt.org/t/nginx-certbot-redirect-https-www-to-https/142678) and I was unable to get the results I want. Testing within web browsers produces varied results, where some times http variants of the URL work, and in other cases they do not. Using a python script as well as using [uptrends.com](http://uptrends.com) show that all http pages fail. The browsers were tried in private tabs to sidestep cache. After being unsuccessful with the steps detailed on that page, I tried modifying the configuration. I had certificate issues when the certificate issued to the root url was being applied to the subdomain, and I also did not see a reason to have a server block for the www subdomain considering this should redirect to root at the DNS level via a CNAME record. Current config attached. Any help resolving this greatly appreciated.
[nginx.txt](https://community.letsencrypt.org/uploads/short-url/dm56IKQf1lKfR5FbhlwiLwQjt9Z.txt) (2.4 KB)
---
### Author:  [@Osiris](https://community.letsencrypt.org/u/Osiris)
#### Post date: [October 18, 2024, 1:12pm UTC](https://community.letsencrypt.org/t/http-to-https-issues/227495/2 "2024-10-18T13:12:25Z")
You can change your nginx configuration all you want, but that's not where the (current) issue is: your IP address is entirely unresponsive on port 80, even though it's responding on port 22 (SSH) and 443 (HTTPS). Most likely a firewall problem blocking access to TCP port 80.
---
### Author:  [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)
#### Post date: [October 18, 2024, 1:21pm UTC](https://community.letsencrypt.org/t/http-to-https-issues/227495/3 "2024-10-18T13:21:15Z")
And, two things about your nginx config
1. You listen for IPv6 in all of your server blocks except the one for port 443 and your www subdomain. This is not harmful at the moment since you do not have an AAAA address in your DNS. But, it is an easy thing to forget or notice if you ever do since your other ones do listen properly
2. Your cert only has your apex name in it. So, requests going directly to your www subdomain will fail as its cert does not include its name
Using a browser is not a great way to test redirects. Something as simple as curl will show what is happening better. Some browsers will try both HTTP and HTTPS simultaneously and use HTTPS if it worked. Other browsers will not.
For example
```nohighlight
curl -I http://www.atasapr.org
curl: (7) Failed to connect to www.atasapr.org port 80 after 47 ms:
No route to host
curl -I https://www.atasapr.org
curl: (60) SSL: no alternative certificate subject name matches
target host name 'www.atasapr.org'
curl -I https://atasapr.org
HTTP/1.1 200 OK
Server: nginx
(...)
```
Oh, and a CNAME record only redirects DNS queries. So, your www subdomain will have the IP for the name it points to. But, the HTTP(S) requests will be handled by your nginx server.
---
### Author:  [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)
#### Post date: [October 20, 2024, 8:09pm UTC](https://community.letsencrypt.org/t/http-to-https-issues/227495/4 "2024-10-20T20:09:38Z")
Hello @ATAS,
Here is a list of issued certificates [crt.sh | atasapr.org](https://crt.sh/?q=atasapr.org)
The most recent certificate was issued by [Let’s Encrypt](https://letsencrypt.org/) previous ones were not. However the important point about the previous certificates is they were certificates containing wildcard domain names. The present certificate only contains the name `atasapr.org`, so `www.atasapr.org` is no longer covered.
The [DNS-01 challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) is the only challenge that "You can use this challenge to issue certificates containing wildcard domain names" of the [Challenge Types - Let's Encrypt](https://letsencrypt.org/docs/challenge-types/)
### Edit
Demonstrating the currently being served certificate [crt.sh | 14529899938](https://crt.sh/?id=14529899938) for both `atasapr.org` and `www.atasapr.org`, which only contains the name `atasapr.org`.
- PASS - `atasapr.org` [https://decoder.link/sslchecker/atasapr.org/443](https://decoder.link/sslchecker/atasapr.org/443)
- FAIL - `www.atasapr.org` [https://decoder.link/sslchecker/www.atasapr.org/443](https://decoder.link/sslchecker/www.atasapr.org/443)
Edit 2:
Maybe you are also looking for [Strict-Transport-Security header - HTTP | MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) (i.e. HSTS).
---
### Author:  [@system](https://community.letsencrypt.org/u/system)
#### Post date: [November 19, 2024, 8:10pm UTC](https://community.letsencrypt.org/t/http-to-https-issues/227495/5 "2024-11-19T20:10:19Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.