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(284.8, 13%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EET%3C/text%3E%3C/svg%3E)
We recently setup Exchange Hybrid on Classic mode. Completed without errors.
During setup we ensure that the Transport Certificate is valid and we assigned our 3rd party cert.
We checked on IIS that "Default Front End" certificates are assigned with 3rd party cert.
IIS 'Exchange Back End' is using the private "Exchange Server" certificate.
When checking Exchange online connectors and validating the O365-Onprem connector, it errors with
"450 4.4.317 Cannot connect to remote server [Message=SubjectMismatch Expected Subject: ...... Thumbprint:######"
When troubleshooting and Checking the certificate thumbprint from the error message on the server. Determined that the thumbprint belonged to the private certificate used in the 'Exchange Back End'
Not sure why it's presenting the wrong certificate and not the front-end certificate?
Normal email flow is still working.
Appreciate anyone's feedback.
![](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(44.800000000000004, 43%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBJ%3C/text%3E%3C/svg%3E)
Hi,@Ella Taylor
This NDR is generated in the following scenarios:
Exchange Online connects to a remote email server, also known as a remote message transfer agent (MTA), to send an email message to an external recipient. During the TLS handshake, the remote MTA sends only a leaf certificate to Exchange Online without including the certificates of the intermediate certification authorities (CAs). If Exchange Online can't validate the authenticity of the certificate by building the chain to a Microsoft-trusted root CA, it generates an NDR for the sender.
A remote MTA connects to Exchange Online to send an email message to an Exchange Online recipient. During the TLS handshake, the remote MTA sends only a leaf certificate to Exchange Online without including the certificates of the intermediate CAs. If Exchange Online can't validate the authenticity of the certificate by building the chain to a Microsoft-trusted root CA, it rejects the email message. The remote MTA then generates an NDR for the sender.
You can refer to the solution below:
If you're an email admin in the remote MTA organization, configure your remote MTA to provide the full certificate chain.
If you're an email admin in the Exchange Online organization, notify an email admin in the remote MTA organization about the NDR.
If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.