MailKit used by ASP.NET Core web application fails to connect to MailEnable SMTP server because of t-CodePudding

The Windows Server 2012 R2 runs MailEnable Standard Version 10.34 and hosts a couple ASP.NET Core web applications in IIS. There is also Plesk Obsidian 18.0.40.

For each web application, an SSL Certificate has been issued and configured in IIS. Those certificated were issued and installed two months ago. In Plesk, each website has a "Lets Encrypt" certificate, too. The Plesk "SSL/TLS Certificates" page looks like the following:

Lets Encrypt mydomain.com  ---> Secures webmail
www.mydomain.com           ---> Secures mail

Suddenly, today, one of the web applications stopped sending emails. The code is the following (where xxx.xxx.xxx.xxx is the server's IP):

using (MailKit.Net.Smtp.SmtpClient smtp = new MailKit.Net.Smtp.SmtpClient()) 
{
    try
    {
        smtp.Connect("xxx.xxx.xxx.xxx", 587, false);
        ...
    }
    catch (Exception ex) { ... }
}

The Connect method fails with exception error:

An error occurred while attempting to establish an SSL or TLS connection. The host name did not match the name given in the server's SSL certificate.

and inner exception error:

The remote certificate is invalid according to the validation procedure.

I checked with MailEnable server and updated the default SSL Certificate by selecting one of the newly issued (by right clicking the server node -> Properties -> SSL tab -> Default SSL Certificate dropdownlist). No other configuration change has been performed on the MailEnable server whatsoever.

The problem remains. Can anyone explain why is this happening and what exactly does it mean? I am not sure where from to start looking for a solution? IIS? Plesk? MailEnable?

I understand this sounds complicated since both code and server components are involved and I am more than willing to provide any further information upon request.

CodePudding user response：

There are many reasons for this error.

For example: The certificate is self-signed and not added as a trusted certificate, The certificate is expired, The certificate is signed by a root certificate that's not installed on your machine, The wrong endpoint, etc.

The more common ones may be:

1. The mail server that you are connecting to is using an expired (or otherwise untrusted) SSL certificate.

Often times, mail servers will use self-signed certificates instead of using a certificate that has been signed by a trusted Certificate Authority. Another potential pitfall is when locally installed anti-virus software replaces the certificate in order to scan web traffic for viruses.

When your system is unable to validate the mail server's certificate because it is not signed by a known and trusted Certificate Authority, the above error will occur.

You can work around this problem by supplying a custom RemoteCertificateValidationCallback and setting it on the client's ServerCertificateValidationCallback property.

For example:

using (var client = new SmtpClient ()) {
    client.ServerCertificateValidationCallback = (s,c,h,e) => true;

    client.Connect (hostName, port, SecureSocketOptions.Auto);

    // ...
}

2. The server does not support the same set of SSL/TLS protocols that the client is configured to use.

MailKit attempts to keep up with the latest security recommendations and so is continuously removing older SSL and TLS protocols that are no longer considered secure from the default configuration. This often means that MailKit's SMTP, POP3 and IMAP clients will fail to connect to servers that are still using older SSL and TLS protocols. Currently, the SSL and TLS protocols that are not supported by default are: SSL v2.0, SSL v3.0, TLS v1.0 and TLS v1.1.

You can override MailKit's default set of supported SSL and TLS protocols by setting the value of the SslProtocols property on your SMTP, POP3 or IMAP client.

For example:

using (var client = new SmtpClient ()) {
    // Allow SSLv3.0 and all versions of TLS
    client.SslProtocols = SslProtocols.Ssl3 | SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12 | SslProtocols.Tls13;

    client.Connect ("smtp.gmail.com", 465, true);

    // ...
}

For more common causes and solutions, please refer to this link.

Hope this can help you.