...第 9.1 节说“实现应该支持 X25519”

虽然您似乎引用了 RFC，但有问题的短语实际上与您引用的内容有很大不同：

9.1。强制实施密码套件

... 应该支持与 X25519 [RFC7748] 的密钥交换。

但是您尝试的是使用带有基于 Ed25519 的公钥的证书进行身份验证，这与使用 X25519 进行密钥交换完全不同。X25519 密钥交换似乎实际上在浏览器中实现，但 Ed25519 证书没有。

...这两个浏览器都没有在其 ClientHello 中提供 Ed25519 作为签名

X25519 中不涉及 Ed25519 签名。X25519 是一种密钥交换 - 受浏览器支持。Ed25519 是一种签名算法 - 不受支持。因此，X25519 和 Ed25519 是不同的东西，它们都使用 Curve25519。

正如@steffan 指出的那样，我将 X25519（ECDH 密钥交换）与 ED25519（数字签名）混淆了。

Chrome 支持 X25519（用于 DH 密钥交换），但不支持 ED25519。

此外，握手中列出的协议不同方面支持的算法不止一处。

比较 wget 和 chromium 的握手：

wget：

铬：

支持密钥交换的曲线在supported_groups扩展中传递。如屏幕截图所示，Chrome 确实在那里提供 X25519。

ED25519 可能会出现在另外两个扩展中。

首先，CertificateVerify用于签署握手的扩展名。“supported_signatures”扩展声明客户端支持哪些签名算法。

其次，证书支持的签名算法。根据 RFC，这应该在“signature_algorithms_cert”扩展中声明，但根据第 4.2.3 节：

“signature_algorithms_cert”扩展适用于证书中的签名，而最初出现在 TLS 1.2 中的“signature_algorithms”扩展适用于 CertificateVerify 消息中的签名。

但：

如果不存在“signature_algorithms_cert”扩展，则“signature_algorithms”扩展也适用于出现在证书中的签名。

最后，第 9.1 节说：

符合 TLS 的应用程序必须支持带有 rsa_pkcs1_sha256（用于证书）、rsa_pss_rsae_sha256（用于 CertificateVerify 和证书）和 ecdsa_secp256r1_sha256 的数字签名。

符合 TLS 的应用程序必须支持与 secp256r1 (NIST P-256) 的密钥交换，并且应该支持与 X25519 [RFC7748] 的密钥交换。