Apparently Chrome does not support secp521r1 EC/DH key exchange. secp521r1... should probably be avoided unless you're targeting FIPS standards (too much security, also designed by NSA) but "higher bits" apparently are sexier than having a more rigorous algorithm than x25519.
... or probably this is very intentional move to block Chrome?
AStonesThrow 5 days ago [-]
I'd be interested to know how you traced this. I dove into the rabbit hole, and used ssllabs.com for a client browser check. I compared the client with the server to note that the server, very strict in its protocols, accepts only TLS v1.3 (check) and only a single CHACHA cipher (check) so I could not see why they were not connecting. Now I do see that Chrome only does ecdh secp384r1 or 256, but that was fine print, and I did not understand its importance.
An attempt to fetch the blog URL with http: also failed with a 404.
Anyway, I did find the blog article, dated May 2022, on the Wayback Machine, in two old snapshots, and attempting to take a snapshot today failed. The W3C Validator was able to fetch and parse anyway.
There was no particular indication of browser compatibility in the blog post. But a very opinionated piece on DNSSEC indeed.
pixl97 5 days ago [-]
Should be able to do something like an
OpenSsl s_client -connect egbert.net:443
And get more information.
Rendered at 07:44:21 GMT+0000 (Coordinated Universal Time) with Vercel.
https://www.ssllabs.com/ssltest/analyze.html?d=egbert.net
... or probably this is very intentional move to block Chrome?
An attempt to fetch the blog URL with http: also failed with a 404.
Anyway, I did find the blog article, dated May 2022, on the Wayback Machine, in two old snapshots, and attempting to take a snapshot today failed. The W3C Validator was able to fetch and parse anyway.
There was no particular indication of browser compatibility in the blog post. But a very opinionated piece on DNSSEC indeed.
OpenSsl s_client -connect egbert.net:443
And get more information.