Unable to send mail to local SMTP server with TLS - ssl

Question

So we have a local exchange server that we use as a SMTP server for our internal servers. I'm trying to fix so it works with TLS but right now it's not.
I have a wildcard certificate assigned to both SMTP and the IIS roles. But When I try to use send-mailmessage through PowerShell for example I am getting.
Send-MailMessage -SmtpServer mail.domain.com -UseSsl -port 465 -From fromaddress
-To tomailaddress -Subject test -BodyAsHtml test -Encoding ([System.Text.Encoding]::UTF8)
The remote certificate is invalid according to the validation procedure.
The certificate used is valid for me when I go to the IIS site (or any other site that uses the same certificate).
So what am I doing wrong? Or how can I troubleshoot this.

Answer 1

Keep noted that the SSL certificate for SMTP couldn´t be managed with the IIS. You need to use powershell here (Enable-ExchangeCertificate) [more infos here].
Example:
Enable-ExchangeCertificate -Thumbprint
434AC224C8459924B26521298CE8834C514856AB -Services SMTP
In general you can troubleshoot such a TLS connection (over port 465) with Openssl (see here for a howto).
The URL also has also some solutions in place, so I will not copy them all here. In general the issues are:
The SSL certificate isn´t fully trusted on the remote machine (or in the keystore, which didn´t apply to your powershell test, but might apply to your 3rd party software)
There is still a self signed SSL certificate in use with SMTP
Conclusion:
I think you still use a self signed ssl certificate on the SMTP port and should change that with the command above.

Answer 2

I had the same issue. First I used the below code to save a copy of the certificate used by the SMTP server (since I didn't have access to the server itself / even if you do have access, this shows which server's being presented so may flag if it's different to what you'd expected). I ran this via LinqPad5 as a c# Program.
void Main()
{
System.Net.ServicePointManager.ServerCertificateValidationCallback = new System.Net.Security.RemoteCertificateValidationCallback(OutputCertificateCallback);
using (System.Net.Mail.SmtpClient S = new System.Net.Mail.SmtpClient("smtprelay.subdomain.example.com"))
{
S.EnableSsl = true;
using (System.Net.Mail.MailMessage M = new System.Net.Mail.MailMessage("john.bevan#example.com", "john.bevan#example.com", "Test", "Test"))
{
try
{
S.Send(M);
Console.WriteLine("Sent");
}
catch (Exception e)
{
Console.WriteLine("Error {0}", e);
}
}
}
}
private bool OutputCertificateCallback(object sender, System.Security.Cryptography.X509Certificates.X509Certificate certificate, System.Security.Cryptography.X509Certificates.X509Chain chain, System.Net.Security.SslPolicyErrors sslPolicyErrors)
{
Console.WriteLine(certificate);
System.IO.File.WriteAllBytes(#"C:\Temp\cert.cer", certificate.Export(System.Security.Cryptography.X509Certificates.X509ContentType.Cert));
var c2 = new System.Security.Cryptography.X509Certificates.X509Certificate2(certificate);
return c2.Verify();
}
I was then able to inspect the certificate by viewing the saved file: C:\Temp\cert.cer
Check the expiry date to ensure the certificate is valid.
If it's not, that's the problem. Get a new certificate.
Check that the root certificate in my client's trusted CAs:
Start, Run, MMC
File > Add/Remove SnapIn > Certificates > Add > My User Account > Finish > OK
Certificates - Current User > Trusted Root Certificate Authorities > Certificates
Search for the root CA (i.e. the one with the same name as your certificate) in this list
If it's not you may need to install the root CA, the intermediary CA, or the certificate itself (which you can do using the file you just saved using the above script).
Check that the port is open on the firewall. You can test this via the below PowerShell:
try {
$tcp = New-Object -TypeName 'system.net.sockets.tcpclient' -ArgumentList 'smtprelay.subdomain.example.com', 465
if ($tcp.Connected) {':)'} else {':('}
} catch {
':('
$_.Exception.Message
}
In my case, all of the above weren't enough to spot the issue. Eventually I realised the service used a wildcard certificate (e.g. *.example.com), but the mail server was on a subdomain (e.g. smtprelay.subdomain.example.com) so wasn't covered by this certificate. Using a wildcard on the subdomain (e.g. *.subdomain.example.com) would have worked; though we just requested that the service be given an explicitly named certificate (for smtprelay.subdomain.example.com), including the service's individual nodes' FQDNs as Subject Alternative Names, in case we ever needed to target a specific node for debugging.