添加这条线对我很有效。这实际上信任这里提到的所有证书。但是，这主要用于故障排除。如果这适用于您，则意味着远程服务器的证书没有作为受信任证书添加到您的计算机中。

System.Net.ServicePointManager.ServerCertificateValidationCallback = new System.Net.Security.RemoteCertificateValidationCallback(RemoteServerCertificateValidationCallback);

完整代码为

private void sendAMail(String toAddress, String messageBody)
        {
            String msg = "Sending mail to : " + toAddress;

            MailMessage mail = new MailMessage();
            mail.To.Add(toAddress);
            mail.From = new MailAddress("from@mydomain.com");
            mail.Subject = "Subject: Test Mail";
            mail.Body = messageBody;
            mail.IsBodyHtml = true;            

            //Added this line here
            System.Net.ServicePointManager.ServerCertificateValidationCallback = new System.Net.Security.RemoteCertificateValidationCallback(RemoteServerCertificateValidationCallback);
            SmtpClient smtp = new SmtpClient();

            smtp.Host = "myhostname.com";            
            smtp.Credentials = new System.Net.NetworkCredential("sender@sample.com", "");
            smtp.EnableSsl = true;
            smtp.Port = 587;            
            smtp.Send(mail);            
        }


private bool RemoteServerCertificateValidationCallback(object sender, System.Security.Cryptography.X509Certificates.X509Certificate certificate, System.Security.Cryptography.X509Certificates.X509Chain chain, System.Net.Security.SslPolicyErrors sslPolicyErrors)
{
    //Console.WriteLine(certificate);
    return true;
}

这有点晚了，但如果您正在寻找像Yury这样的解决方案，下面的代码将帮助您确定问题是否与自签名证书有关，如果是，则忽略自签名错误。如果需要，显然可以检查其他SSL错误。

我们使用的代码(由Microsoft - http://msdn.microsoft.com/en-us/library/office/dd633677(v=exchg.80).aspx提供)如下:

  private static bool CertificateValidationCallBack(
         object sender,
         System.Security.Cryptography.X509Certificates.X509Certificate certificate,
         System.Security.Cryptography.X509Certificates.X509Chain chain,
         System.Net.Security.SslPolicyErrors sslPolicyErrors)
    {
  // If the certificate is a valid, signed certificate, return true.
  if (sslPolicyErrors == System.Net.Security.SslPolicyErrors.None)
  {
    return true;
  }

  // If there are errors in the certificate chain, look at each error to determine the cause.
  if ((sslPolicyErrors & System.Net.Security.SslPolicyErrors.RemoteCertificateChainErrors) != 0)
  {
    if (chain != null && chain.ChainStatus != null)
    {
      foreach (System.Security.Cryptography.X509Certificates.X509ChainStatus status in chain.ChainStatus)
      {
        if ((certificate.Subject == certificate.Issuer) &&
           (status.Status == System.Security.Cryptography.X509Certificates.X509ChainStatusFlags.UntrustedRoot))
        {
          // Self-signed certificates with an untrusted root are valid. 
          continue;
        }
        else
        {
          if (status.Status != System.Security.Cryptography.X509Certificates.X509ChainStatusFlags.NoError)
          {
            // If there are any other errors in the certificate chain, the certificate is invalid,
         // so the method returns false.
            return false;
          }
        }
      }
    }

    // When processing reaches this line, the only errors in the certificate chain are 
// untrusted root errors for self-signed certificates. These certificates are valid
// for default Exchange server installations, so return true.
    return true;
  }
  else
  {
 // In all other cases, return false.
    return false;
  }
}

这是我决定使用的解决方案。

        ServicePointManager.ServerCertificateValidationCallback = delegate (object s, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
        {
            string name = certificate.Subject;

            DateTime expirationDate = DateTime.Parse(certificate.GetExpirationDateString());

            if (sslPolicyErrors == SslPolicyErrors.None || (sslPolicyErrors == SslPolicyErrors.RemoteCertificateNameMismatch && name.EndsWith(".acceptabledomain.com") && expirationDate > DateTime.Now))
            {
                return true;
            }
            return false;
        };

这里的链接解决了我的问题。

http://brainof-dave.blogspot.com.au/2008/08/remote-certificate-is-invalid-according.html

我去到web服务的url(在有问题的服务器上)，点击IE中的小安全图标，弹出证书。然后，我单击Details选项卡，单击Copy To File按钮，这允许我将证书导出为.cer文件。在本地获得证书后，我就可以使用下面的说明将其导入服务器上的证书存储区。

开始一个新的MMC。 文件——>添加/删除管理单元… 单击Add…… 选择“证书”，单击“添加”。 选中“计算机帐户”单选按钮。单击Next。

在下一个屏幕中选择客户端计算机。单击Finish。 单击Close。 单击OK。 现在将证书安装到受信任的根证书颁发机构证书存储区中。这将允许所有用户信任该证书。

接受的答案中的代码帮助我调试问题。然后我意识到证书参数的SN字段与我认为的SMTP服务器不相同。通过将SmtpClient实例的Host属性设置为证书的SN值，我能够解决这个问题。

我有完全相同的问题，并找出默认情况下，邮件屏蔽从Avast反病毒有“扫描SSL连接”激活。一定要把它关掉。

据我所知，Avast将“打开”邮件，扫描任何病毒，然后使用它自己的证书进行签名，这样邮件就不会被gmail的证书所签名，从而产生错误。

解决方案1:

关闭SSL扫描从你的防病毒(或整个邮件屏蔽)。

解决方案2(应该是最好的安全来说):

以某种方式获得反病毒使用的证书(Avast有一个选项可以导出它) 在连接到gmail服务器之前，将其导入imap/pop/smtp客户端。