In GNOME Web, I am shown a warning about an expired certificate for forums.puri.sm.
4 Likes
When attempting to browse directly on GNOME web, it does not connect showing Invalid Response. For GNOME Web, the cert expired today. Firefox ESR is unaffected.
1 Like
I don’t know how the dates are extracted. Browser bug or are there two certificates? 4 days apart seems a little odd, but could be a single bit error.
2 Likes
As viewed by me (Firefox) the certificate shows:
Not After Sun, 12 Oct 2025 23:59:59 GMT
i.e. expiring soon but not yet. @praveen.arimbrathodi ?
If using something like Let’s Encrypt with very short validity periods (e.g. 3 months) then renewal is supposed to be an automated process but I think we all know that sometimes automated processes don’t. 
On the other hand, Brave says Expires On Friday 13 June 2025 at 00:00:00 but still claims that the connection is secure. WTA?
And Epiphany says Not Valid After 2025-10-07 and claims that the connection is not secure due to expired certificate.
Needs more investigation‽
Who can say? It is certainly possible for a web site to be mirrored across multiple servers, either outsourced to a company like Cloudflare or implemented directly by the owner of the web site. (I have my doubts that Purism would want to use the former approach though as it usually means surrendering the private key(s) of your certificate(s).)
When you mirror a web site in this way, of course you are supposed to keep the certificate on each mirror unexpired but, the more servers, the more likely that something goes wrong somewhere. (Some companies may want to have a unique certificate on each mirror and some companies may want to deploy the same certificate to each mirror.)
In addition, every individual certificate is actually multiple certificates because of the need for the chain of Certificate Authorities up to a built-in certificate root. However checking the rest of the chain right now (as viewed by me) they are both years away from expiry, as is usually the case.
2 Likes
It still makes me confused as to why I can’t even navigate to it on Epiphany, not a deal-breaker, but weird.
2 Likes
After deleting the webapp, it’s like that, either direct URL to the site or navigating through a search engine fails to load the URL
1 Like
Certificate renewals are handled by discourse docker itself. There looks to be a fix related to letsencrypt certificate renewals, which is likely to fix the issue. I will update discourse_docker and deploy it on 10th between 6-8 am UTC.
2 Likes
discourse_docker and discourse updated, this fixed the invalid certificate issue.
2 Likes
Confirming that Firefox now reports Not After Thu, 08 Jan 2026 06:04:14 GMT
will test other browsers …
- Epiphany happy
- Brave happy
4 Likes
Yes it’s working once more
1 Like
Well, it better, as in the future all certificate lifetimes are significantly reduced (down to 47 days, about 1.5moths), starting next year (in steps 2026, 2027 and 2029). This should be a security improvement, we’ll see if it makes life annoying to small entities. A good post about it (warning, big internet entities involved): TLS Certificate Lifetimes Will Officially Reduce to 47 Days | DigiCert
2 Likes
I wonder what a browser will do with a certificate that exceeds the current maximum lifetime at the time. Presumably this can only arise with self-signed certificates.
In other words, is this the CA world saying that we will only issue certificates with progressively shorter lifetimes but a browser should simply accept every certificate that is within its validity period or is this also the browser world saying that we will only accept a certificate within its first X days of validity where X is whatever the lifetime has been reduced to by CA world?
I would tentatively guess that browsers will still accept all valid certificates. If not then I know for a fact that some embedded commercial equipment will fail e.g. I have an example here where the self-signed certificate expires in about 20 years time. Suck on that, Apple!
For me though, it comes back to what I wrote above
Some companies may want to have a unique certificate on each mirror
because once you are automatically renewing certificates constantly, there are bound to be stuff-ups from time to time and it is better that things degrade gracefully (one or more mirrors give silly errors while all other mirrors work 100% normally) rather than the entire company is off the web for Y hours.
Yes, it seems as if this will increase the burden on small entities, even when automation mostly works.
I don’t think this change is really addressing the major underlying problem though, stated as
The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.
Right, so it’s OK for a certificate with bogus information to be accepted for 47 days?
1 Like
It depends on your threat model.
Apparently it doesn’t though. 
Apple has decided (and Google has fallen into line) … that 47 days is right for everyone, regardless of threat model / security requirements / situation / …
If a fraudulent certificate exists for the domain of a public web site, I can’t think of a realistic scenario where it would be acceptable to leave that certificate in use for 47 days - assuming that the web site needed to use TLS in the first place. But, OK, for some users of that web site they might really not care and just click to accept the dodgy certificate anyway.
It is not quite as dire as I suggest though because browsers are supposed still to implement CRL and OCSP (for 47 day certificates).
2 Likes