SMTP服务器与发件人域名不一致导致证书信任错误的解决咨询

首先得明确你的问题根源：当你用SmtpClient连接mail.in.xyz.com并启用SSL时，客户端会做两项关键验证：

1. 检查服务器返回的证书域名是否和连接的Host（mail.in.xyz.com）一致
2. 验证证书的根CA是否在本地信任存储中

现在服务器返回的是in.xyz.com的自签名证书——既不满足域名匹配要求（证书的CN/SAN字段里没有mail.in.xyz.com），这个自签名的根证书也不在你的信任列表里，所以触发了日志里的证书错误。

下面给你不同场景下的解决方案：

1. 生产环境最安全的根治方案：修复SMTP服务器证书 #

这是从根源解决问题的最优解：

• 联系运维团队，为mail.in.xyz.com申请并安装匹配域名的SSL证书：
  • 如果是内部环境，用XYZ信任的内部CA签发证书，确保证书的CN是mail.in.xyz.com，或者SAN（主题备用名称）字段包含该域名
  • 如果是公网环境，用公共CA（比如Let's Encrypt）签发对应域名的证书
• 同时确保签发证书的根CA已被所有客户端机器的信任存储收录
• 配置完成后，你的现有代码不需要任何修改就能正常发送邮件

2. 测试/调试环境临时方案：绕过证书验证 #

如果你只是在测试环境验证功能，不想花时间配置证书，可以临时关闭证书验证（生产环境绝对禁止这么做，会完全暴露在中间人攻击风险下）：
在创建SmtpClient实例之前，添加这段代码：

// 临时绕过所有SSL证书验证，仅用于测试！
System.Net.ServicePointManager.ServerCertificateValidationCallback += 
    (sender, certificate, chain, sslPolicyErrors) => true;

这段代码会强制让客户端接受任何证书，但请记住上线前一定要删除它。

3. 内部环境折中方案：导入信任自签名证书+修正证书域名 #

如果你们内部只能使用自签名证书：

1. 修正证书域名：让运维重新生成in.xyz.com的自签名证书，在SAN字段里添加mail.in.xyz.com，确保证书能匹配SMTP服务器的Host
2. 导入信任证书：把这个自签名证书导入到所有客户端机器的「受信任的根证书颁发机构」存储中（Windows下可以通过certmgr.msc操作）
   这样客户端会信任该证书，同时域名匹配，错误就会消失。

另外补充：SmtpClient本身没有提供指定证书的API，它完全依赖操作系统的证书信任机制和服务器返回的证书是否符合连接Host的验证要求，所以核心还是解决证书的匹配和信任问题。

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