locked
Changing FQDN for default receive connector? RRS feed

  • Question

  • Hi all,

    Our public cert for Exchange is bound to IMAP, POP, IIS and SMTP.  Previously, we had a self signed internal cert assigned to these services.

    Since then, the event log has been filled with the following error:

    Microsoft Exchange could not find a certificate that contains the domain name EXCHANGE in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector CUSTOM with a FQDN parameter of EXCHANGE. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

    This is because the server name is not included in the public cert.  For other non-default connectors, we have been changing the authentication to uncheck "Exchange Server authentication" (not sure why this is checked on non-default connectors), and updating the connector's FQDN for HELO responses to a FQDN that is included in the public cert to remove errors for that connector.

    So far, this has not caused any issues for non-default connectors on either of our Exchange servers.  I am hesitant to disable "Exchange Server authentication" on the default connector, but wondered if anyone had experience doing so?  If not, please advise on what steps should be taken to remedy these errors.

    Friday, May 1, 2015 1:47 PM

Answers

  • Hi ,

    Please have a look in to the below mentioned article and it may help you on this case.

    https://social.technet.microsoft.com/Forums/office/en-US/1d0d3425-9fd3-4519-abb1-dcc216892009/exchange-2013-receive-connectors?forum=exchangesvrsecuremessaging


    Thanks & Regards S.Nithyanandham

    • Marked as answer by 5801ptbac Monday, May 4, 2015 5:10 PM
    Saturday, May 2, 2015 5:18 AM
  • Hi ,

    Please have a look in to the below mentioned article and it may help you on this case.

    https://social.technet.microsoft.com/Forums/office/en-US/1d0d3425-9fd3-4519-abb1-dcc216892009/exchange-2013-receive-connectors?forum=exchangesvrsecuremessaging


    Thanks & Regards S.Nithyanandham

    Thank you.  Straight from https://technet.microsoft.com/en-us/library/bb125140(v=exchg.141).aspx:

    "Don’t modify the FQDN value on the default Receive connector Default <Server Name> that's automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the Default <Server Name> Receive connector, internal mail flow between Hub Transport servers fails."

    Either we need to include the server name in our public cert or issue a separate self signed internal cert and associate it with SMTP.

    • Marked as answer by Niko.Cheng Tuesday, May 19, 2015 1:57 AM
    Monday, May 4, 2015 5:11 PM

All replies

  • How many servers do you have in your organization?  I ask because Exchange uses TLS to secure all traffic between servers, and if it can't secure the traffic, it will stop email delivery.  Since you say this hasn't caused any issues, I have to assume you have a single-server configuration.

    As for disabling Exchange Server Authentication, if you do this, you open your system to the possibility of becoming an open relay.  A better solution would be for you to place one of the names from your public certificate as the FQDN on your connector.  So if the SAN on your public certificate includes mail.company.com, you would run Set-ReceiveConnector <connector ID> -FQDN <FQDN from certificate>.

    Friday, May 1, 2015 2:37 PM
  • We have two servers in different locations, but both are hub transport servers in the same domain.  If I try to specify a different FQDN on the default connector, it gives an error of:

    • --------------------------------------------------------
      Microsoft Exchange Error
      --------------------------------------------------------
      The following error(s) occurred while saving changes:
    • Set-ReceiveConnector
      Failed
      Error:
      If the AuthMechanism attribute on a Receive connector contains the value ExchangeServer, you must set the FQDN parameter on the Receive connector to one of the following values: the FQDN of the transport server "EXCHANGE.domain.com", the NetBIOS name of the transport server "EXCHANGE", or $null.

     For non-default connectors that connect various non-Exchange servers for e-mail, I found that by disabling "Exchange Server authentication", I was able to update the FQDN.


    Friday, May 1, 2015 4:08 PM
  • Hi ,

    Please have a look in to the below mentioned article and it may help you on this case.

    https://social.technet.microsoft.com/Forums/office/en-US/1d0d3425-9fd3-4519-abb1-dcc216892009/exchange-2013-receive-connectors?forum=exchangesvrsecuremessaging


    Thanks & Regards S.Nithyanandham

    • Marked as answer by 5801ptbac Monday, May 4, 2015 5:10 PM
    Saturday, May 2, 2015 5:18 AM
  • Hi ,

    Please have a look in to the below mentioned article and it may help you on this case.

    https://social.technet.microsoft.com/Forums/office/en-US/1d0d3425-9fd3-4519-abb1-dcc216892009/exchange-2013-receive-connectors?forum=exchangesvrsecuremessaging


    Thanks & Regards S.Nithyanandham

    Thank you.  Straight from https://technet.microsoft.com/en-us/library/bb125140(v=exchg.141).aspx:

    "Don’t modify the FQDN value on the default Receive connector Default <Server Name> that's automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the Default <Server Name> Receive connector, internal mail flow between Hub Transport servers fails."

    Either we need to include the server name in our public cert or issue a separate self signed internal cert and associate it with SMTP.

    • Marked as answer by Niko.Cheng Tuesday, May 19, 2015 1:57 AM
    Monday, May 4, 2015 5:11 PM