# Why is the Apple Touch Icon loaded via HTTP instead of HTTPS?
**URL:** https://meta.discourse.org/t/why-is-the-apple-touch-icon-loaded-via-http-instead-of-https/104501
**Category:** Support
**Created:** [12월 17, 2018, 9:53오후 UTC](https://meta.discourse.org/t/why-is-the-apple-touch-icon-loaded-via-http-instead-of-https/104501 "2018-12-17T21:53:15Z")
**Posts on this page:** 20
**Page:** 1
Every other image is loaded via HTTPS, this is the only exception.
I need to fix this in order to force HTTPS site-wide.
Am I doing something wrong?
---
> [@pfaffman](#):
>
> Search site settings for “http://”.
Thanks for your reply!
This is what I get:
> [@pfaffman](#):
>
> You might also have forced the image in a custom theme.
Not sure what you mean by that. I’ve just created a new theme and added the logos, icons and favicon. All via admin settings/dashboard. That’s the only resource served via HTTP for whatever reason.
PS: Happy B’day! 🍰
---
> [@pfaffman](#):
>
> You might try running `/wizard` and see if that’ll let you change the logo to an https version.
Already tried that with no success.
If I reset the icon I get a default path for the Discourse placeholder, which is still served via HTTP:
``
---
> [@Graphiwiz](#):
>
> Can I _un-force_ https if I run into trouble?
Yes, you can disable the ‘force https’ setting by unchecking the setting. If for some reason enabling the setting locks you out of your site, you can disable it through the rails console with:
```plaintext
SiteSetting.force_https = false
```
---
> [@simon](#):
>
> Yes, you can disable the ‘force https’ setting by unchecking the setting. If for some reason enabling the setting locks you out of your site, you can disable it through the rails console with:
After forcing https, it seems to be working now, I get no errors but there seems to be an issue for the security certificate though.
I get this in Firefox only when accessing [https://WWW.community.mysite.com](https://WWW.community.mysite.com):
`The certificate is only valid for community.mysite.com. Error code: SSL_ERROR_BAD_CERT_DOMAIN`
Note that the following work perfectly (ALL redirect to [https://community.mysite.com](https://community.mysite.com), except [https://www](https://www) in FF):
- [https://community.mysite.com](https://community.mysite.com)
- [www.community.mysite.com](http://www.community.mysite.com)
- [community.mysite.com](http://community.mysite.com)
- [http://community.mysite.com](http://community.mysite.com)
- [http://www.community.mysite.com](http://www.community.mysite.com)
Although [https://WWW.community.mysite.com](https://WWW.community.mysite.com) also redirects to [https://community.mysite.com](https://community.mysite.com) in Chrome and it works as expected, Firefox does **not** redirect and instead shows that error and blocks the site.
I configured my `app.yml` file using this guide: [Set up Let’s Encrypt with multiple domains / redirects](https://meta.discourse.org/t/setting-up-let-s-encrypt-with-multiple-domains/56685) and added a redirect from www to the non-www version following this guide: [(Superseded) Redirect additional domain(s) to your Discourse instance](https://meta.discourse.org/t/redirect-single-multiple-domain-s-to-your-discourse-instance/18492)
---
Yep, you can’t publish over HTTPS reliably without that setting being enabled. It’s why it warns you every time you visit the dashboard that it has to be set.
As you’ve not shared your site URL we can’t look at the certificate to verify if you’ve configured it correctly, but that error suggests you’ve missed a subject alternate name. It’s only going to be used for the redirect, but once you’ve corrected your certificate the error will go away.
---
> [@Stephen](#):
>
> that error suggests you’ve missed a subject alternate name. It’s only going to be used for the redirect, but once you’ve corrected your certificate the error will go away.
Thanks for your input.
So essentially I should add a redirect from the [https://www](https://www) version to https:// – is that what you’re implying?
EDIT: Just wanted to stress that the [https://www](https://www) is currently only redirecting to https:// in Chrome. Firefox is blocking the site.
Currently I only have this redirect:
```
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
server_name www.community.example.com;
return 301 $scheme://community.example.com$request_uri;
}
```
---
I’m not implying anything, if you’re getting an HTTPS error for www that means you’ve configured a server directive to listen on an HTTPS URL, but the associated certificate lacks the **S** ubject **A** lternate **N** ame for WWW. Your Let’s Encrypt request will need to request any additional domains passed in using -d as specified in the guide you linked above:
```
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /-k 4096 -w \/var\/www\/discourse\/public/
to: |
-d www.main-domain.com -d second-domain.com -d www.second-domain.com -d other-domain.com -d www.other-domain.com -k 4096 -w /var/www/discourse/public
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /-k 4096 --force -w \/var\/www\/discourse\/public/
to: |
-d www.main-domain.com -d second-domain.com -d www.second-domain.com -d other-domain.com -d www.other-domain.com -k 4096 --force -w /var/www/discourse/public
```
With the real production domain names specified in place of the examples. I can’t check the state of the certificate you’re using as you’ve not provided any real link to your site.
This will only be for the redirect as you can’t publish Discourse itself via multiple URLs. Strictly speaking you shouldn’t need a server directive at all for [https://www](https://www).\* unless for some reason you published that URL at some point. If you didn’t then you’re over-engineering your configuration.
---
I’m sorry, without real details for the site to troubleshoot you’re probably on your own here.
There are ways to step through the problem and identify the cause, but we can’t even begin to employ such methods when you’re artificially limiting and redacting aspects of your setup.
---
> [@codinghorror](#):
>
> Are you using Cloudflare or some other “magically add HTTPS through trickery” service?
No, I am not. Absolutely no magic tricks.
---
Your symptoms are implying that firefox is being case sensitive where Chrome is not. If you add a WWW version to the let’s encrypt domain list does that make Firefox happy?
[다음 페이지](https://meta.discourse.org/t/why-is-the-apple-touch-icon-loaded-via-http-instead-of-https/104501.md?page=2)