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

Product Support

AI-generated summary

Paul_King reported that since September 30, 2021, his site https://www.nzarchitecture.net.nz triggers a browser certificate error (NET::ERR_CERT_COMMON_NAME_INVALID) because the Let’s Encrypt certificate is issued for nzarchitecture.net.nz without the ‘www’. This caused Facebook to flag the site as non-compliant, disabling Facebook login. While the certificate is valid as confirmed by IAmGav, Facebook requires the exact domain registered with them — in this case, the non-www version — and won’t accept mixed usage. Paul_King’s DISCOURSE_HOSTNAME was correctly set to nzarchitecture.net.nz post 7, but users accessing via ‘www’ still saw warnings. Falco clarified that ‘www’ is not an alias but requires a proper redirect with its own certificate post 9. Paul_King sought a way to extend the existing Let’s Encrypt certificate to cover both domains without added cost or complexity. JammyDodger and Simon_Manning provided a solution: adding a custom Let’s Encrypt command in app.yml to include the www subdomain during certificate generation. After correcting indentation and rebuilding, the fix worked perfectly, resolving both the certificate warning and Facebook compliance issue post 14.

1

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.

2

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

the cert is 100% legit

3

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

4

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

5

in your config file

/var/discourse/containers/app.yml

what is your DISCOURSE_HOSTNAME: set to ?

6

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.

7

app.yml shows

DISCOURSE_HOSTNAME: nzarchitecture.net.nz

8

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…

9

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/

10

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)

11

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

12

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?

13

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.

14

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