Why is the Apple Touch Icon loaded via HTTP instead of HTTPS?

support
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.

Capture
Capture.PNG927×69 3.42 KB

Am I doing something wrong?

1 Like
2

Search site settings for “http://”.

You might also have forced the image in a custom theme.

3 Likes
3

Thanks for your reply!

This is what I get:

Capture2
Capture2.PNG1187×356 11.8 KB

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! :cake:

1 Like
4

You might try running /wizard and see if that’ll let you change the logo to an https version.

5

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:

<link rel="apple-touch-icon" type="image/png" href="http://community.mysite.com/images/default-apple-touch-icon.png">

6

Tested on fresh install with default themes. Still can’t fix this.

7

Have you tried turning on force-https?

2 Likes
8

No. Can I un-force https if I run into trouble?

9

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:

SiteSetting.force_https = false
8 Likes
10

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:

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, except https://www in FF):

Although https://WWW.community.mysite.com also redirects to 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: Setting up Let’s Encrypt with Multiple Domains and added a redirect from www to the non-www version following this guide: Redirect single/multiple domain(s) to your Discourse instance

11

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.

1 Like
12

Thanks for your input.

So essentially I should add a redirect from the https://www version to https:// – is that what you’re implying?

EDIT: Just wanted to stress that the 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;
      }
13

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 Subject Alternate Name 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.* unless for some reason you published that URL at some point. If you didn’t then you’re over-engineering your configuration.

4 Likes
14

Interesting but I don’t understand why it’s working in Chrome perfectly and only FF is displaying the error.

Here is my app.yml ssl config:

  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /-k 4096 -w \/var\/www\/discourse\/public/
        to: |
          -d www.example.com -d www.community.example.com -d example.com -d community.example.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.example.com -d www.community.example.com -d example.com -d community.example.com -k 4096 --force -w /var/www/discourse/public

    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301 https.+/
        to: |
        return 301 https://$host$request_uri;

    - replace:
         filename: "/etc/nginx/conf.d/discourse.conf"
         from: /gzip on;[^\}]+\}/m
         to: |
         gzip on;
         add_header Strict-Transport-Security 'max-age=31536000';
15

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.

16

The only thing I masked was the actual website name: example. The rest of the details are not redacted in any way.

17

They are, because I can’t inspect the headers and redirects to a fictional URL. Good luck resolving this anyhow.

18

Are you using Cloudflare or some other “magically add HTTPS through trickery” service?

2 Likes
19

No, I am not. Absolutely no magic tricks.

2 Likes
20

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?

1 Like