最可靠方式是直接比较 cert.NotAfter DateTime.UtcNow，因 NotBefore/NotAfter 为 UTC 时间且 Kind 为 DateTimeKind.Utc，避免本地时钟偏差。
如何在 C# 中检查 X509Certificate2 是否已过期
直接看证书的 NotBefore 和 NotAfter 属性是最可靠、最轻量的方式，不需要发起网络请求或依赖系统时间同步服务。
常见错误是只比对 DateTime.Now，却忽略本地时钟偏差或证书使用的是 UTC 时间——其实 NotBefore/NotAfter 返回值已经是 DateTime 类型且带 Kind == DateTimeKind.Utc，直接用 DateTime.UtcNow 比较才准确。
- 用
cert.NotAfter 判断是否已过期（注意不是 <code>，证书在 <code>NotAfter当天 23:59:59 仍有效） - 用
cert.NotBefore > DateTime.UtcNow判断是否尚未生效（例如刚签发但起效时间设为未来） - 若需兼容本地时区逻辑，统一转成 UTC：
DateTime.Now.ToUniversalTime()，但不推荐，容易引入歧义
HttpClient 默认 SSL 验证失败时怎么拿到具体错误原因
默认情况下 HttpClient 会静默失败并抛出 HttpRequestException，根本看不到是证书过期、域名不匹配还是根证书缺失。必须通过 HttpClientHandler.ServerCertificateCustomValidationCallback 拦截原始验证过程。
这个回调函数的第四个参数 sslPolicyErrors 是关键，它是一个位掩码，可能包含：SslPolicyErrors.None、SslPolicyErrors.RemoteCertificateNotAvailable、SslPolicyErrors.RemoteCertificateNameMismatch、SslPolicyErrors.RemoteCertificateChainErrors 等。
- 当
sslPolicyErrors包含RemoteCertificateChainErrors，可进一步检查certificate.GetIssuerName()和certificate.Verify()结果 - 若想只放行“过期”错误（调试用），可写：
return (sslPolicyErrors & ~SslPolicyErrors.RemoteCertificateChainErrors) == SslPolicyErrors.None || sslPolicyErrors == SslPolicyErrors.RemoteCertificateChainErrors;—— 但生产环境严禁这样写 - 注意：.NET 5+ 中
HttpClientHandler的ServerCertificateCustomValidationCallback默认为null，即启用系统默认验证；一旦赋值，就完全接管，包括本该通过的合法证书
为什么调用 HttpClient.SendAsync 后抛出“Authentication failed because the remote party has closed the transport stream”
这不是证书过期的典型报错，而是 TLS 握手阶段被服务器主动终止，常见于服务端配置了严格证书策略（如仅接受特定 CA、禁用旧版 TLS 协议），而客户端未适配。
典型诱因是 .NET Framework 默认使用 TLS 1.0/1.1，而现代 HTTPS 服务普遍要求 TLS 1.2+；.NET Core/.NET 5+ 默认支持 TLS 1.2，但若项目降级到旧目标框架或运行在老旧 Windows 上，仍可能失败。
- 强制启用 TLS 1.2（全局生效，建议放在应用启动处）：
ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12; - 检查服务器实际支持的协议：可用
openssl s_client -connect example.com:443 -tls1_2验证 - 如果用的是
HttpClientHandler实例，还可设置handler.SslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13;（.NET Core 2.1+） - 注意：Windows Server 2008 R2 默认不支持 TLS 1.2，需打补丁或升级系统
自签名证书或私有 CA 证书怎么让 HttpClient 接受
不能靠关闭验证（如返回 true）来“解决”，这等于放弃 HTTPS 安全性。正确做法是将私有根证书导入当前用户或机器的证书存储，并确保 X509Chain 能构建完整信任链。
若无法导入系统存储（如容器环境、无管理员权限），可手动加载根证书参与链验证：
var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = (httpRequestMessage, cert, certChain, sslPolicyErrors) =>
{
if (sslPolicyErrors == SslPolicyErrors.None) return true;
<pre class="brush:php;toolbar:false;">var chain = new X509Chain();
chain.ChainPolicy.TrustMode = X509ChainTrustMode.CustomRootTrust;
chain.ChainPolicy.CustomTrustStore.Add(yourRootCert); // yourRootCert 是 X509Certificate2 实例
chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck; // 内网环境常关闭吊销检查
return chain.Build(cert);};
容易被忽略的是：自签名证书本身没有 issuer，chain.Build() 会失败，此时应单独判断 cert.Issuer == cert.Subject 并跳过链验证，或直接比对指纹。
