none
Exchange 2013 Hybrid ( with Exchange online) - Outgoing mail flow to Exchange Online - error in mail queue on Edge server = 454 4.7.5 The cerfificate specified in TLS CertificatioName of the SendConnector could not be found

    Question

  • Hello,

    I'm looking for some pointers on how to resolve the below error.

    Here's my Setup:

    - Exchange 2013 CU13 Hybrid setup with Office 365 tenancy - on-premise servers are multi-role servers

    - Exchange Edge servers plus edge sync setup to handle ALL outgoing mail and only incoming mail from Office 365 via TLS

    - Have public certificates on Mailbox/ client access servers and on the EDGE server. ( CN names of certificates are different but contain the same subject alternative names)

    - Incoming mail handled by on-premise Barracuda servers

    - I can send mail out of Edge servers to Exchange Online servers on port 25.  When I open a telent session I see the STARTTLS command so this confirms that my public cert on my edge server is correct

    - I have run the Hybrid Configuration wizard multiple times

    My problem is that I can receive mail from Exchange Online via SMPT TLS but I am unable to send mail via secure TLS from on-premise to Exchange online.  The error I see in the mail queue on my Edge server is as follows: "454 4.7,. The certificate specified in TLS Certification Name (CN) of the SendConnector could not be found.

    I have research issue by reading many articles.  I can in a way understand the error as the CN on the mailbox/client access server has a CN of  outlook.test.com whilst on the edge server the CN is edge13.test.com.  As I have edge sync setup I have changed the CN of the send connector that the Hybrid wizards generates for "outbound to Office 365" to match the CN of the public certificate on the Edge server but this does not resolve the issue.

    I am unable to change the name of the send connector on the Edge server because I have edge synchronisation in place.

    Has anyone seen this error before ? My next set is to recreate the Public Certificate on the Edge server with a CN which matches the CN on the mailbox / client access server.  The hybrid wizard is run on the mailbox / client access server so therefore uses the CN of the public certificate installed on MB/CA , it has no visibility of the edge server.

    Any thought ?????

    thanks in advance , Joe

    Monday, May 1, 2017 2:26 PM

Answers

  • Thanks for you comments ED, it's appreciated.

    Agree totally with your statement about the use of a Barracuda server.  In our setup the Barracuda currently process only in-coming email.  The Edge server process out-going email and is the TLS end point for our mail flow to and from our Office 365 tenancy. Long term when our all our onsite mail boxes are migrated to our Office 365 tenancy the Barracuda servers will be decommissioned.  

    Have resolved issue.

    In case anyone else comes across the same issue, here's how I resolved the issue......My problem was caused by not using the same Cert name on my Client access/Hub server as the cert on my Edge server certificate.  I resolved the problem by:

    • Setting the FQDN of the Office 365 Send connector , created by the Hybrid wizard, on my client access\hub server to match the FQDN of my Edge server
    • Set the TLSCertificateName on the Office 365send connector on my client access/ hub server to match the CN of the certificate on my Edge server
    • Ran start-EdgeSyncronization to update send connector on my edge server
    • I am not able to route mail via TLS to our Office 365 tenancy

    regards, Rob.

    • Marked as answer by Rob Garbutt Tuesday, May 2, 2017 10:45 AM
    Tuesday, May 2, 2017 10:45 AM

All replies

  • First, your hybrid connectors should never go through a device like a Barracuda, the Exchange server should connect directly to Exchange Online Protection and vice-versa.  Putting a non-Exchange message hygiene device or other relay between on-premises Exchange and cloud Exchange risks all sorts of issues.

    Second, your certificate should match the Internet DNS name corresponding to the IP address, either in the CN or a SAN.

    Third, you can indeed change the Edge connectors but you just do it in the on-premises Exchange server.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Monday, May 1, 2017 10:14 PM
    Moderator
  • Thanks for you comments ED, it's appreciated.

    Agree totally with your statement about the use of a Barracuda server.  In our setup the Barracuda currently process only in-coming email.  The Edge server process out-going email and is the TLS end point for our mail flow to and from our Office 365 tenancy. Long term when our all our onsite mail boxes are migrated to our Office 365 tenancy the Barracuda servers will be decommissioned.  

    Have resolved issue.

    In case anyone else comes across the same issue, here's how I resolved the issue......My problem was caused by not using the same Cert name on my Client access/Hub server as the cert on my Edge server certificate.  I resolved the problem by:

    • Setting the FQDN of the Office 365 Send connector , created by the Hybrid wizard, on my client access\hub server to match the FQDN of my Edge server
    • Set the TLSCertificateName on the Office 365send connector on my client access/ hub server to match the CN of the certificate on my Edge server
    • Ran start-EdgeSyncronization to update send connector on my edge server
    • I am not able to route mail via TLS to our Office 365 tenancy

    regards, Rob.

    Tuesday, May 2, 2017 10:44 AM
  • Thanks for you comments ED, it's appreciated.

    Agree totally with your statement about the use of a Barracuda server.  In our setup the Barracuda currently process only in-coming email.  The Edge server process out-going email and is the TLS end point for our mail flow to and from our Office 365 tenancy. Long term when our all our onsite mail boxes are migrated to our Office 365 tenancy the Barracuda servers will be decommissioned.  

    Have resolved issue.

    In case anyone else comes across the same issue, here's how I resolved the issue......My problem was caused by not using the same Cert name on my Client access/Hub server as the cert on my Edge server certificate.  I resolved the problem by:

    • Setting the FQDN of the Office 365 Send connector , created by the Hybrid wizard, on my client access\hub server to match the FQDN of my Edge server
    • Set the TLSCertificateName on the Office 365send connector on my client access/ hub server to match the CN of the certificate on my Edge server
    • Ran start-EdgeSyncronization to update send connector on my edge server
    • I am not able to route mail via TLS to our Office 365 tenancy

    regards, Rob.

    • Marked as answer by Rob Garbutt Tuesday, May 2, 2017 10:45 AM
    Tuesday, May 2, 2017 10:45 AM