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


(Stephen) #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.


#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;
      }

(Stephen) #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.


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

(Stephen) #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.


(Stephen) #17

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


(Jeff Atwood) #18

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


#19

No, I am not. Absolutely no magic tricks.


(Brahn) #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?


#21

Worth a shot, thanks!


#22

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:

SSL_ERROR_BAD_CERT_DOMAIN

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


Setting up HTTPS support with Let's Encrypt
(Brahn) #23

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


#24

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?


#25

Hours later… tried pretty much everything and I still can’t get it to work.

In case I do have a breakthrough, I will update thread for future reference.


(Brahn) #26

Yes, you should be expecting to get one certificate containing multiple entries in the Subject Alternative Name field.

From Setting up HTTPS support with Let’s Encrypt:

If you delete those two directories before rebuilding the container you can be sure that it will get fresh certificates when you rebuild.


#29

Thanks! Yes, I always removed the old cert files before rebuilding with no success.

Just woke up now so I’m ready for another 12 hours of research, until I get to the bottom of this. I am starting everything from scratch on a new Lightsail instance.

Will update on the first bump.


#30

UPDATE: I managed to make the www version on FF secure as well. All I did was remove the root domain (the one without the forum install) from the list: -d example.com -d www.example.com and all I have left is the actual forum -d community.example.com -d www.community.example.com. Not sure why that helped to be honest.

NEW ISSUE: Now I’ve got two different websites: the www doesn’t redirect to the non-www version like it did before for whatever reason.


#31

Fixed by adding this 301 redirect to my app.yml hooks section:

- file:
    path: /etc/nginx/conf.d/discourse_redirect_1.conf
    contents: |
      server {
        listen 443;
        server_name www.community.example.com;
        return 301 $scheme://community.example.com$request_uri;
      }

(system) closed #32

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.