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

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">

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

Have you tried turning on force-https?


No. 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:

SiteSetting.force_https = false

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

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

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;

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:

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


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:

    - 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';

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.

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

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

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?

1 Like

Worth a shot, thanks!

I’ve added -d WWW.community.example.com but https://www.community.example.com still doesn’t redirect in FF.

This is what I get in FF:


www.community.example.com uses an invalid security certificate.

The certificate is only valid for community.example.com.

Unable to communicate securely with peer: requested domain name does not match the server’s certificate.

HTTP Strict Transport Security: false HTTP Public Key Pinning: false

The certificate should list all the domains you have included, can you see them? Perhaps the certificate is not being recreated with the list of domains when you rebuild? Follow the debugging instructions in Setting up HTTPS support with Let’s Encrypt

1 Like

1. For ./launcher logs app I can see:

www.example.com:Verify error:DNS problem: NXDOMAIN looking up A for www.example.com

(that’s for the root, not for the discourse install, which is under www.community.example.com)

And also:

Reload error for : Started runsvdir, PID is 326
ssyslogd: command 'KLogPermitNonKernelFacility' is currently not permitted

Domains not changed.
Add '--force' to force to renew.
Installing key to:/shared/ssl/comunity.example.com.key
Run reload cmd: sv reload nginx

2. For ls -l /var/discourse/shared/standalone/ssl I get:

total 8
-rw-r--r-- 1 ubuntu root 3924 Dec 18 03:56 community.example.com.cer
-rw------- 1 ubuntu root 3247 Dec 18 04:24 community.example.com.key

Should I try and manually reissue the cert following instructions here Setting up HTTPS support with Let's Encrypt?