Facebook login was flagged as non compliant by Facebook after change to Let's Encrypt certificate system

[Paul_King]

Since around September 30th 2021 (as far as I can tell) my site has been generating certificate errors

your connection is not private
NET::ERR_CERT_COMMON_NAME_INVALID’ security warning.

This server couldn’t prove that it’s www.nzarchitecture.net.nz ; its security certificate is from nzarchitecture.net.nz . This may be caused by a misconfiguration or an attacker intercepting your connection.

This issue may relate to Let’s Encrypt changes implemented on that date.
The issue is triggered when url https://www.nzarchitecture.net.nz is used, but not when https://nzarchitecture.net.nz is used

The issue persists, even after updating to 2.8.0 beta 7, and doing full rebuild.

A consequence of the error message appearing on my landing page is that the site is flagged as no longer meeting Facebook requirements, meaning Facebook login has been disabled by Facebook.

[IAmGav (Gavin Perch)]

it’s an facebook issue that they need to fix.

the cert is 100% legit

https://www.sslshopper.com/ssl-checker.html#hostname=nzarchitecture.net.nz

[anon73664359]

That seems similar to…
https://meta.discourse.org/t/configuring-google-login-for-discourse/15858/239

[Paul_King]

The thing is that even I see these errors when including ‘www’ in the url I paste/type into browser - so even though there is no actual risk, users are being hit with worrying warnings. with or without the Facebook compliance issue.

Facebook meanwhile refuse to review the matter until the error disappears

[IAmGav (Gavin Perch)]

in your config file

/var/discourse/containers/app.yml

what is your DISCOURSE_HOSTNAME: set to ?

[Falco]

@Paul_King

The issue is triggered when url https://www.nzarchitecture.net.nz is used, but not when https://nzarchitecture.net.nz is used

If you real site is under the non-www domain, you must register the non-www domain in the Facebook system. Can’t mix and mingle that.

[Paul_King]

app.yml shows

DISCOURSE_HOSTNAME: nzarchitecture.net.nz

[Paul_King]

@Falco

If you real site is under the non-www domain, you must register the non-www domain in the Facebook system. Can’t mix and mingle that.

OK, I suppose that makes sense - but from a DNS point of view one is an alias of the other (or so I believed) - and it is is going to be hard to tell the average user that they can’t use ‘www’ - especially if they need to log in to see any warning to that affect…

[Falco]

It’s not really an “alias” but a redirect. And you need to properly configure a redirect, which includes having a certificate in place for the place the redirect lives.

For example, our partners at communiteq provide a service for that at https://www.forcewww.com/

[Paul_King]

@Falco

It’s not really an “alias” but a redirect. And you need to properly configure a redirect, which includes having a certificate in place for the place the redirect lives.

Until recently, this had never been a problem - no Facebook warning, and no certificate warnings with or without the www.

Is there any way to get the default free Let’s Encrypt’ certificate to certify both options? Keen not to complicate things with extra certificates to manage and extra cost

There are a lot of emails out there with links to the site that include the www.

By ‘the place the redirect lives’ do you mean Digital Ocean in this case? (my host, and where DNS settings are managed from)

[JammyDodger]

@Paul_King

Is there any way to get the default free Let’s Encrypt’ certificate to certify both options? Keen not to complicate things with extra certificates to manage and extra cost

You can add an extra line or two to your app.yml. This worked for me when I was having issues:

Set up Let’s Encrypt with multiple domains / redirects

This is to address the problem where you get certificate errors with any redirects or CNAME DNS entries which point to your actual installed Discourse (sub)domain. If you do not have https configured already (you do if you have done a standard install recently) see Setting up Let’s Encrypt as your first step. There are two patterns that need to be replaced, one ending in --keylength, and another ending in --fullchainpath (in the actual file, your original domain is before each of these switche…

[Paul_King]

Thanks - that seems promising

in my case, if https://nzarchitecture.net is the base domain, would the correct lines to add be as below?

after_ssl:
- replace:
filename: “/etc/runit/1.d/letsencrypt”
from: /–keylength/
to: “-d www.nzarchitecture.net.nz --keylength”

and do I have to rebuild discourse for this to take effect?

[Simon_Manning]

The content is right but indentation is important in the yml file, so that needs to be corrected:

  after_ssl:
    - replace:
        filename: “/etc/runit/1.d/letsencrypt”
        from: /--keylength/
        to: “-d www.nzarchitecture.net.nz --keylength”

You will need to rebuild for it to take effect.

Edit: Actually it looks like the use of --keylength has been replaced by -k, so you’ll need the following instead:
Apologies, my Github search lead me to an old fork without me noticing. --keylength is correct.

[Paul_King]

Fantastic! Thanks so much for your help @Simon_Manning and everybody - that redirect via app.yml worked a treat.