This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(67.2, 79%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKS%3C/text%3E%3C/svg%3E)
We recently migrated our on-prem Exchange servers from 2013 to 2019. The servers are only used for SMTP relay as our mailboxes have all been migrated to 365. On the receive connectors we created for relay we did not assign a certificate but when connecting with telnet and entering the Ehlo command we do see STARTTLS advertised. However, some our printer/scanners are no longer able to send email and are getting "SMTP over SSL failed".
My questions is, do we need to assign a certificate to the receive connectors? We have a cert installed on the server that is assigned to SMTP but not to the relay connectors specifically so just wondering if that is recommended or required.
Thank you
Ok, Cool, in that case I suspect the printers are using TLS 1.0/1.1 and in Exchange 2019 that is deprecated.
Assuming you cant upgrade those devices to 1.2, is TLS required on that receive connector?
-RequireTLS it should be $false
If it is set to $false, can you disable the TLS sending on one of the devices and test?
RequireTLS is set to False on those receive connectors. We are checking on what version of TLS those printers are using. We have some printers that are still able to send mail and they are using TLS 1.2 so what you say makes sense. I'm curious, though, what would be a reason to assign the certificate directly to the receive connector? Doesn't seem like it should be necessary but not sure.
Yea no reason to set the cert unless you were enforcing TLS such as when in hybrid or with a partner.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 22%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKY%3C/text%3E%3C/svg%3E)
Hi @Kenny Stern
Do suggestions above help?
If you have any questions or needed further help on this issue, please feel free to post back.
If the issue has been resolved, please accept the helpful replies as answers, this will make answer searching in the forum easier and be beneficial to other community members as well.
Thank you, Andy. You nailed it.
Are the receive connectors created exactly the same as they were on the 2013 servers including Remote IP Ranges?
What connector are the printers attempting to use? You can verify in the SMTP protocol logs
The logs will show what connector is being used when it fails.
The 2013 servers were set up before I worked here and did not have dedicated receive connectors for relay. Instead they had modified the default frontend ones, which I've always heard is bad practice. So on the new servers i elected to create dedicated receive connectors. The default frontend on the 2013's do have a certificate assigned. The relay ones on 2019 do not.
Well, the FQDN of the receive connectors is used and that matches up with a subject name of a cert that is installed for SMTP on the Exch Server. IF no FQDN is defined, then it should use the default cert of the server since that is the host name.
I'd be curious what the SMTP protocol shows and what connector these devices are attempting to use
The connector being used is the relay connector from what I'm seeing in the protocol logs. I'm also seeing some "TLS negotiation failed with error SocketError"entries. We do have a cert assigned to SMTP and the FQDN on these receive connectors does match the name on the cert.