CassandrichSep 1, 2025
Uh, do @hachyderm staff know there's been an expired certificate for at least an hour or so now? https://status.hachyderm.io shows no problem and at least some other folks don't seem to have noticed anything so I'm guessing it's a problem only with certain nodes.
hachyderm.io status

Show threadCassandrich

Related: I want to call out Firefox mobile for atrociously bad security UX around bad certs. The cert error message reads: "Fennec does not trust https : // hachyderm.io / because its certificate issuer is unknown, the certificate is self-signed, or the server is not sending the correct intermediate certificates."

This muddling of multiple error conditions, which becomes an outright LIE when the actual error is the main one that appears in the real world (expiration or wrong clock), makes it impossible to act on and fuels wrongful fears that a site has been compromised.

Sep 1, 2025 at 4:18pmWeb
Show threadCassandrichSep 1, 2025
In this case it wasn't going to let me act on the information anyway (and provided an even worse message I didn't save) due to HSTS, but deleting the HSTS store to get the real error produced the above, with an option to override, but no way to get the information necessary to evaluate whether an override is safe.
Show threadCassandrichSep 1, 2025

On another level, while standard TLS handling of expiry is reasonable in a standalone connection context, it's bullshit to begin with in a web context.

There is no reasonable sense in which a certificate that I trusted 5s ago is suddenly untrusted because 5s passed.

Browser UX should be something like continuing to trust an expired cert for up to 3-4 days (whatever expected reasonable turnaround time for an admin to act is) as long as:

- The certificate is identical to the one you last trusted it as (in particular, this ensures no rollback).
- You accessed the site within a few days prior to expiry (this ensures compromised certs can't be used against infrequent visitors long after compromise).

Along with a clear UI element explaining that the site has failed to renew its certificate in time but that this does not indicate a compromise, and that it will stop working at [date and time] unless they resolve this.

Show threadCassandrichSep 1, 2025
Also, disallowing HSTS override without rm'ing files in the profile directory is a shit anti-user behavior by browsers.
Show threadFalcon DarkstarSep 1, 2025
@dalias alternatively: the certificate should expire when the domain registration expires, at least if it contains a name for a second level domain, and should be revoked if domain ownership changes. Or we should use DANE.
Show threadCassandrichSep 1, 2025
@falcon You want certs to be much more short-lived than domain registration so that you don't have to rely on revocation. And there's no way evaluate registration lifetime anyway except "registrar says so in the whois text" which isn't really suited for cryptographic trust use. Just sticking to short lifetimes ensures certs will have very short validity past transfer of ownership tho, which is probably fine since nobody launches an important service right after domain transfer.
Show threadFalcon DarkstarSep 2, 2025

@dalias I am not sure I agree. There may be some legitimate interest in a shorter time to reduce CRL size, but also certificates should in most cases be revoked if a domain is transferred to an unrelated party. The status quo is even worse, forcing people to age domains and make guesses.

Also, what the registrar says is the literal source of record for domain ownership.

But with DANE, this would all happen automatically and certificate expiration would just not be a thing.

Show threadCassandrichSep 2, 2025
@falcon I'm just saying there's no protocol level way to know domain registration period or transfer of ownership. On top of that, I tend to view the fact that transfer of ownership is possible as a bug. It breaks trust of people using the domain name and, even ignoring certificate issues, can cause a user's browser to disclose secrets to a new party they don't trust. I deem the new owner more of a threat than the old owner still having an unexpired certificate.
Show threadFalcon DarkstarSep 2, 2025
@dalias the problem space goes deep. While we are talking radical ideas, it makes little sense that your anchor for e.g. TD.com being your bank is the fact that they pay a nominal sum to CSC Global and Verisign therefore maintains that the site points to them. One wants a stronger anchor that could prove it's your bank regardless of DNS, but the UI and frankly the social infrastructure to tie that up failed in EV certificates and remains unexplored otherwise.
Show threadCassandrichSep 2, 2025
@falcon EV was attempting to verify entirely the wrong thing, which is why it was so hated and eventually made irrelevant.
Show threadFalcon DarkstarSep 3, 2025
@dalias it was also fairly useless because it required users to look at things in the address bar. What is needed is some way to allow users to express their intent in human terms, and then check automatically that the counterparty is who the user expects it to be.
Show threadChris JohnsonSep 1, 2025
@dalias Great usability and security ideas! Would love to see browser makers implement them.
Show threadJohn BreenSep 1, 2025
@dalias Amen. Your post reminded me of this from a Brave browser a few days ago, operated by a human, with a correct clock...
What in hell is anyone supposed to do with that error description...
Show threadKevin Karhan Sep 1, 2025
@dalias maybe let @mozilla_support know about this if this isn't already ticketed as a #bug...
Show threadMozilla SupportSep 2, 2025
@kkarhan @dalias Hey folks, please file a ticket on https://bugzilla.mozilla.org/ to report that issue. Thanks!
Bugzilla Main Page