The issue revolves around a bug in the force_https setting in Discourse, where it fails to enable automatically when a valid certificate is present, leading to mixed-content warnings and broken uploads. pfaffman discovered the problem after debugging a site where uploads failed, only to find that enabling force_https resolved it. The root cause is a failing certificate validation due to the expiration of the Let’s Encrypt DST Root CA X3 certificate and issues with the ISRG Root X1 trust chain in older OpenSSL versions (1.1.1d). RGJ explains that force_https should be enabled by default if a valid cert exists, but the test fails because of outdated certificate trust chains. The problem is further linked to acme.sh being pinned to an older version (2.9.0) lacking support for default chain settings, which may have contributed to certificate reissuance issues. Falco acknowledged the issue, assigned it to himself, and resolved it with a fix in the Discourse Docker repository 8e2ccee. IAmGav thanked Falco for the fix.
Edit: changing this to a bug. Force_https is now off on sites where it used to be on and that breaks things.
I spent a while debugging a site where “uploads don’t work”. After going through a litany of obvious things (rebuild, safe-mode, consider non-standard plugins), I finally noticed a mixed-content warning and turned on force_https, and we’re back in business.
I thought that at some time a year or two ago that force_https was on by default, but a few times recently I’ve heard of (or perhaps seen) that things were broken because force_https wasn’t turned on.
Is there a reason not to have it on by default?
[/quote]
I spent a while debugging a site where “uploads don’t work”. After going through a litany of obvious things (rebuild, safe-mode, consider non-standard plugins), I finally noticed a mixed-content warning and turned on force_https, and we’re back in business.
I thought that at some time a year or two ago that force_https was on by default, but a few times recently I’ve heard of (or perhaps seen) that things were broken because force_https wasn’t turned on.
So the issue is that the test for a valid cert is failing:
# openssl verify -CAfile ca.cer fullchain.cer
O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 3 depth lookup: certificate has expired
error fullchain.cer: verification failed
And then, if I remove mozilla/DST_Root_CA_X3.crt from /etc/ca-certificates.conf and update-ca-certificates, I then get this:
C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 2 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
It shows up fine in the browser. And I just rebuilt this container today (so it should have the updated root certs).
I don’t know enough about this cert stuff to know just what’s up with that. I can curl a let’s encrypt certificate from inside the container (a test that was failing on a WordPress container I was working with last week).
OMG. ANd I spent two days debugging an issue that I thought was some intricate issue with Rails and Ansible and Python, but turned out to be that my server that used to have force_https turned on , doesn’t now, and a bunch of requests were made to http://myserver rather than https://myserver.
We were moving a forum to another server last week and we ran into the LetsEncrypt reissuance limit (max 5 per week for the same hostname). At first we had no idea why but this bug caused the certificate to be reissued on every build and after five times it ran into the rate limit. That didn’t ring any alarms because the previous certificate was still on the server.
Until we moved the forum to a new server. Then we did not get a fresh certificate. We could copy it from the old server but we never realized what caused it.
Hey @Falco. Do you want to take a look at this? You seem to be well versed in these matters. I’ve poked at this for several hours over the past week or two and still don’t understand what’s going on.
