.NET Core 3.1升级后SmtpClient邮件发送失败问题排查

我来帮你拆解这个问题的根源，并给出从临时应急到长期合规的解决方案——你遇到的是.NET Core 3.x跨平台证书验证逻辑收紧，加上Ubuntu环境CA证书识别差异导致的典型问题。

问题根源分析 #

1. .NET Core版本升级带来的验证逻辑变化：从2.2升级到3.1后，.NET对SSL证书链的验证严格程度提升了，尤其是在非Windows平台，默认会强制检查证书吊销列表（CRL）和完整的信任链；而2.2版本的验证逻辑相对宽松，很多情况下会自动跳过这类检查。
2. Ubuntu系统CA证书路径的识别问题：Ubuntu的系统信任CA证书存在/etc/ssl/certs/目录，但.NET Core 3.x在Ubuntu环境下默认可能无法自动识别这个路径，导致验证SMTP服务器（比如smtp.gmail.com）的证书时，找不到根颁发机构（GTS CA 1O1）的证书，从而触发PartialChain错误。
3. CRL获取失败的影响：当网络环境无法访问证书的CRL服务器时，默认的验证逻辑会直接判定证书无效，这就是你切换到MailKit后遇到RevocationStatusUnknown错误的原因。

分步解决方案 #

1. 临时应急方案（仅限测试/紧急恢复） #

如果需要快速恢复服务，可以通过自定义证书验证回调跳过部分检查，但注意这会降低安全性，不建议长期在生产环境使用：

针对System.Net.Mail.SmtpClient

由于这个类没有直接暴露证书验证回调，你可以设置全局的验证回调（注意：这会影响整个应用的所有SSL证书验证）：

// 在应用启动时设置（比如Program.cs或Startup.cs）
ServicePointManager.ServerCertificateValidationCallback = (sender, cert, chain, errors) => 
{
    // 推荐：只信任目标SMTP服务器的特定证书（通过指纹验证）
    if (cert.Thumbprint.Equals("你的SMTP服务器证书指纹", StringComparison.OrdinalIgnoreCase))
        return true;
    
    // 不推荐：跳过所有证书验证（极度不安全）
    // return true;
    
    // 默认逻辑：只有无错误时才通过
    return errors == SslPolicyErrors.None;
};

针对MailKit.SmtpClient

MailKit提供了更灵活的回调配置，你可以关闭CRL检查并添加自定义验证逻辑：

using (var client = new MailKit.Net.Smtp.SmtpClient())
{
    // 关闭CRL检查（解决RevocationStatusUnknown问题）
    client.CheckCertificateRevocation = false;
    
    client.ServerCertificateValidationCallback = (sender, cert, chain, errors) =>
    {
        // 验证目标证书指纹（最安全的临时方式）
        if (cert.Thumbprint.Equals("SMTP_SERVER_CERT_THUMBPRINT", StringComparison.OrdinalIgnoreCase))
            return true;
        
        // 处理PartialChain错误：手动验证根CA是否为信任机构
        if (errors == SslPolicyErrors.RemoteCertificateChainErrors)
        {
            foreach (var status in chain.ChainStatus)
            {
                if (status.Status == X509ChainStatusFlags.PartialChain 
                    && status.StatusInformation.Contains("unable to get local issuer certificate"))
                {
                    // 验证根证书是否是你信任的CA（比如Google的GTS CA 1O1）
                    if (chain.ChainElements[^1].Certificate.Subject == "CN=GTS CA 1O1, O=Google Trust Services, C=US")
                        return true;
                }
            }
        }
        
        return errors == SslPolicyErrors.None;
    };
    
    await client.ConnectAsync(_options.MailServiceHost, _options.MailServicePort, SecureSocketOptions.SslOnConnect);
    // 后续的认证、发送邮件逻辑...
}

2. 长期合规解决方案（推荐） #

让.NET Core自动识别Ubuntu的系统CA证书存储，从根源解决证书链验证问题：

方式一：设置环境变量

在启动应用前，指定SSL相关的环境变量，指向Ubuntu的CA证书路径：

# 临时设置（启动应用前执行）
export SSL_CERT_DIR=/etc/ssl/certs/
# 或者指向合并后的CA证书文件（Ubuntu通常有这个文件）
export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt

如果你的应用是通过systemd管理的，可以在服务配置文件（比如/etc/systemd/system/your-api.service）中添加环境变量：

[Service]
Environment="SSL_CERT_DIR=/etc/ssl/certs/"

设置后重启服务，.NET Core就会自动加载系统信任的CA证书，无需修改代码。

方式二：代码中手动加载系统CA证书

如果环境变量设置不方便，可以在代码中手动加载Ubuntu的CA证书并添加到验证链：

// 在应用启动时加载系统CA证书
var systemCaCerts = new X509Certificate2Collection();
var certDir = "/etc/ssl/certs/";
foreach (var certPath in Directory.GetFiles(certDir, "*.pem"))
{
    try
    {
        var cert = new X509Certificate2(File.ReadAllBytes(certPath));
        systemCaCerts.Add(cert);
    }
    catch (Exception ex)
    {
        // 忽略加载失败的证书，避免影响应用启动
        _logger.LogWarning(ex, $"Failed to load CA certificate from {certPath}");
    }
}

// 在MailKit的验证回调中使用这些证书
client.ServerCertificateValidationCallback = (sender, cert, chain, errors) =>
{
    // 将系统CA证书添加到验证链的额外存储
    chain.ChainPolicy.ExtraStore.AddRange(systemCaCerts);
    // 关闭CRL检查（如果网络无法访问CRL服务器）
    chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;
    
    // 重新构建证书链并验证
    var isValid = chain.Build(cert);
    return isValid;
};

3. 官方问题跟进 #

你已经向.NET团队提交了该问题，可以关注官方的修复进展。不过目前上述方案已经可以解决生产环境的问题。

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