TCP流量加密与证书固定：.NET客户端实现的安全问询

1. 当前.NET代码的潜在安全风险 #

• 绕过证书名称校验的风险：如果直接忽略SslPolicyErrors.RemoteCertificateNameMismatch错误，等于放弃验证证书与目标服务器的身份绑定关系。攻击者可使用其他合法但不属于你的服务器的证书（比如同根CA签发的其他域名证书）发起中间人攻击，客户端会毫无察觉地信任恶意服务器。
• TLS版本降级风险：虽然要求版本不低于1.2，但未明确指定具体版本时，部分平台的.NET运行时可能存在兼容逻辑，理论上存在被攻击者诱导使用TLS 1.0/1.1等已废弃漏洞版本的可能。
• 证书固定逻辑不严谨的风险：仅通过X509Chain.ChainPolicy.CustomTrustStore配置信任库，未额外校验证书的唯一标识（如SHA-256指纹），一旦信任库被篡改（混入恶意证书），客户端会信任任何该信任库签发的证书，完全失去证书固定的意义。
• 跨平台行为不一致的隐性风险：MacOS MAUI与WSL Ubuntu上的校验结果差异，说明验证逻辑依赖平台底层安全框架的默认行为，后续在iOS、Windows桌面等平台部署时，可能出现不可预见的校验失败或过度宽松的安全漏洞。

2. 关于subjectAltName字段与忽略错误的合理性 #

• 必须添加subjectAltName字段：现代TLS校验标准（尤其是苹果平台的Security Framework，MAUI在MacOS上依赖该框架）优先使用subjectAltName字段验证服务器域名，传统的CN字段已被弱化。如果证书未配置subjectAltName，即使CN与服务器域名匹配，MacOS等平台也会判定为名称不匹配错误，这正是你遇到跨平台差异的根本原因。
• 证书固定时忽略sslPolicyErrors完全不合理：证书固定的核心是精准验证服务器身份，而非放宽校验。正确做法是：
  • 确保服务器证书在自定义信任库中；
  • 手动校验证书的subjectAltName（或CN）是否与目标服务器域名匹配；
  • 额外校验证书的指纹（如SHA-256哈希），确认是预先固定的证书；
  • 只有所有校验项通过，才接受证书，任何一项失败都拒绝建立连接。
    直接忽略错误等于完全放弃TLS的身份验证能力，证书固定的安全防护作用荡然无存。

内容的提问来源于stack exchange，提问作者groverboy