Interestingly, it also doesn't allow the CA that it's serving, at least per the CAA records:

  w3.org.                 3599 IN SOA ns1.w3.org. hostmaster.w3.org. (
                                  2021060201 ; serial
                                  28800      ; refresh (8 hours)
                                  3600       ; retry (1 hour)
                                  604800     ; expire (1 week)
                                  1800       ; minimum (30 minutes)
                                  )
  w3.org.                 3599 IN CAA 0 issuewild "sectigo.com"
  w3.org.                 3599 IN CAA 0 iodef "mailto:[email protected]"
  w3.org.                 3599 IN CAA 0 issue "amazon.com"
  w3.org.                 3599 IN CAA 0 issue "sectigo.com"
  w3.org.                 3599 IN CAA 0 issue "letsencrypt.org"

It does look like the records were updated recently.

The spf records are also interesting, but I know nothing about their mail setup.

A new Gandi cert was just issued: https://crt.sh/?id=4630660228 Perhaps it just needs a kick, or it'll be fixed soon.

CAA only applies at time of issue. Its totally valid for your CAA records to not match the cert you are using, as long as CAA was ok at issue time.

Which it appears that it was not, at the time that cert was issued!

I have no idea if CAB have made CAA a requirement, but I presume not.

It has been since 2017 afaik https://archive.cabforum.org/pipermail/public/2017-March/009...

Oh, self-correction, Gandi is a Sectico delegate.

They might use the same certificate on the backends as well, and have the frontend load balancer verifying certificates to prevent MITM.

Wow what a neat little trick!

"Neat" is one word for it, sure.

It's nothing wrong with a user deciding "I realize something is wrong, and I shouldn't trust that anything on this website is legitimate, and I shouldn't give it any information, but I'd still like to read the story/article/blog."

There should be a low-opacity button inside the "Advanced" menu.

I have a button there: https://i.judge.sh/each/Star/chrome_qziy165xYV.png

But if the button isn't there, that's probably because w3 has HSTS enabled (for past visitors), which tells the browser to never load unencrypted. The `thisisunsafe` workaround is there to be a middle ground between actually making it impossible to load and preventing users loading an unsecure page when they shouldn't.

People don't read buttons. However, I share your disdain for Chrome's chosen method; it's very gate-keepery. It requires you to be "in the know"; those who understand the danger but haven't heard of the trick are deliberately left out.

I think a reasonable compromise would be a button that pulls up a dialog prompting you to type out a consent message. The dialog tells you what to write instead of keeping this as esoteric knowledge, but the user is still compelled to at least read the warning instead of blindly pressing buttons.

Compare to firefox which has no bypass.

This is the sort of thing, if you're not in the know than you probably dont understand the consequences.

> This is the sort of thing, if you're not in the know than you probably dont understand the consequences.

Understanding the premise and importance of HTTPS and knowing about some esoteric hidden UX of some Google software are not at all the same thing.

Kinda agree, but they don't have a button probably to prevent people from habitually pressing the button to continue. Training your users to bypass security measures is not good security.

For the same UI related reasons that makes confirmation dialogs useless.

(For them, undo is a much better replacement. Even gmail's 'fake' undo for unsending email.)

They added a button in the form of a hackers only keyboard command.

Engineers can be so out of touch sometimes.

Does anyone know how to "thisisunsafe" on mobile Chrome?

I clicked Advanced and then it shows Proceed (unsafe)...

I don't get that option, and instead get a message referencing HSTS, presumably because at some point in the past my browser picked up the HSTS setting for the site.

No look at the cert - it did expire today

Thing is it’s not just the certificate that’s down, the website behind the expired certificate is also down. The two are almost certainly connected, though cause and effect is uncertain.

Yeah if i had to guess the backend is using the same cert

Same thing.