I'm able to reproduce this with Firefox 123.0.1 and Firefox 124.0 on two different systems on two different networks, but wasn't able to reproduce it on a third with Firefox 121 or 124.
I got the message with Fedora Workstation 39 and Kinoite 39 but not Budgie Atomic 39. 🫠
I tested with certs generated from certbot, cert-manager, and caddy, both freshly renewed and months old and these all behaved the same.
@vwbusguy it's gotta be something with a setting, could it be from the enterprise CA management settings? i'm not getting it on my installs of the same versions from a vanilla source build.
@raptor85 Interesting. It also makes no sense to me that I can reproduce it with Kinoite but not Budgie Atomic. Those are both ostree and use the same rpm source for Firefox.
@vwbusguy these pictured are auto-enabled in a source build, are they off by default on one of the distros, they might push different settings for the browsers even at the same version.
edit: nope, not this, i thought it could be these settings as they control using your system CAs but i turned them off and all my Lets Encrypt certs don't show the error
@vwbusguy in ~/.mozilla/firefox/ under whichever profile is yours grab the prefs.js file between the working/not working browsers and run a diff on them, aside from timestamps on some things there's likely a difference in setting being pushed by system policy i'd imagine.
For good measure, I don't get this with chromium or curl on the same machines. Only Firefox, which is consistent with the messaging. This suggests it's something to do with Firefox and not Fedora, but the fact that I don't see this on Budgie Atomic has me second guessing everything.
OK, I think I've figured it out and it might be a me problem. Because cert-manager and Red Hat-ish systems can't agree on whether or not the spec requires an explicit chain, at some point I added the LE intermediary cert into my CA anchors and that's what Firefox is now grumping about. I fixed TLS for CLI tools but now Firefox is complaining about it. Never saw that before today and I check TLS certs with it fairly regularly.
@vwbusguy where can I read about explicit chains? And are CA anchors what I call the trust store (the store of trusted certificates, usually only roots)?
It's a very longwinded debate however. Red Hat interprets the spec as explicit. Cert Manager, browser vendors, and others don't agree and everyone else in between has to find workarounds for stuff being broken that otherwise shouldn't be because of that disagreement.
@mdione As of now, cert-manager refuses to give an option to just do the full chain because they view it as unnecessary and wasteful, but they get requests over it regularly. Likewise, Red Hat has refused to budge in their belief that they are simply following the spec.
@vwbusguy can you reproduce this on other sites secured with let's encrypt? I just checked one of my sites using one of their certs and Firefox for Android is just fine?
I have noticed in the past that occasionally it's a little slow to recognize when a new cert is installed, particularly when it's the first time being issued for a domain.
@deathkitten Yes. Keep in mind that if the CA is in the OS trust store (ie, Android in this case), then the page will still work. It only shows this notice when you inspect the cert.
None of these are for newly issued certs, but I did just renew one for good measure and still got the warning with the renewed cert.
@vwbusguy I looked at the cert for both a personal site and the instance I'm posting on, both from Firefox for Android and Firefox developer edition. I'm not seeing this anywhere. I also had an update waiting on the Developer edition, and saw the same thing before and after restart to upgrade.
I'm not sure how ibe.social gets its Let's Encrypt cert, but I know the one on my personal site uses whatever bespoke thing that Dreamhost set up in its control panel to get certificates for their customers.
Can you let me know one or more of the domains you're seeing this on, so I can look in my browser? If you want to see the domains I've checked from my end, it would be sfintel.space and ibe.social
@deathkitten What's weird is, I'm able to reproduce it with Firefox 123.1 and 124 on multiple systems, but not all of them. I get this message from Fedora Workstation 39 and Fedora Kinoite 39, but I don't with Fedora Atomic Budgie 39.
It seems to be all LE sites, AFAICT, when it happens. Tried with certs generated from certbot, caddy server, and cert-manager.
@vwbusguy Is this just regular Firefox, Developer edition, or something else?
For data collection purposes, I'm using developer edition 125.0b4 (64-bit) on pop_OS!
I hope this is just a wrinkle that'll get sorted shortly, because if this is an indication of some sort of falling out between Firefox/Mozilla and Let's Encrypt, it's going to be a major problem considering how many sites out there are using Let's Encrypt. Especially in light of the bullshit anti-Ad blocker changes that Google has coming for Chrome. >.<
@deathkitten It's regular Firefox from the Fedora update repositories. Tested on three different Fedora 39 variants on two different networks.
The fact that I don't see it on the same Firefox version with Budgie Atomic but I do with Kinoite is very strange, since they're both Atomic from the same rpm source.
@sesivany For the record, the website still works because Fedora still trusts the CA. Mozilla seems to have taken the strict route where Fedora took the path of "let's not break half the internet for our users".
@vwbusguy@sesivany Well, they used to have an intermediate certificate C signed by root A and root B¹. Then A expired (the CentOS 6 thing I mention), then C did or was simply replaced by intermediate D, signed only by B.
If I get it right from the error message, you OS trusts B but ffox doesn't?
¹ reading that I start to suspect it doesn't make any sense.
Add comment