Link to home
Start Free TrialLog in
Avatar of hcca
hcca

asked on

Exchange 2013 multiple certificates assigned to SMTP

I have a GoDaddy SAN cert for my Exchange 2013 servers with a number of Subject Alternative Names. I installed this cert and assigned it to use it for IMAP, POP, SMTP, and IIS. It is the certificate assigned in bindings to the Default Web Site.

All my Exchange 2013 servers are multi-role with the Mailbox and FrontEnd functions covered on the each server.

My issue is that I have two additional certificates, "Microsoft Exchange Server Auth Certificate" assigned to SMTP,  and "Microsoft Exchange" assigned to SMTP and IIS. When I attempt to edit the services assigned to either of these latter two certs, I find the SMTP option checked but grayed out so that I cannot uncheck it.

I'm see issues where some SMTP requests are picking up these self-signed certs and breaking some scanners, printers, and send-as options for Gmail users.

Is this the way this is supposed to work? It seems amiss but i'm not sure how best to resolve. Any help greatly appreciated.
ASKER CERTIFIED SOLUTION
Avatar of Todd Nelson
Todd Nelson
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of hcca
hcca

ASKER

All of the users sending and receiving content from these devices use AD/Exchange accounts in the same AD Domain. As such, I don't think an external relay is needed.

In fact, my tests with an anonymous account from an appliance works. Perhaps, this only applies to authenticated accounts where TLS is used.

This was working until last week. Many of these devices are using authentication to make their connections. The only changes made were last week I installed Windows Server updates. That seems to be what broke things. Last night I upgraded all servers to CU13 hoping that would resolve it, but it did not.

The problem manifests itself in a few ways:
  1. SMTP connections fail to send
  2. Messages sent by users who use Gmail's ability to "Send-As" with an authenticated account receive an NDR after 24-28 hours.
  3. Also seeing difficulty in completing auto discovery profile creation with users in a domain with whom we have a trust relationship.

I'm not sure the last issue is related however.

I can provide some related log entries from the TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend, TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive,  and TransportRoles\Logs\FrontEnd\Connectivity if it would help.
Avatar of hcca

ASKER

Creating a dedicated receive connector resolved my problems. I still do not understand why it was necessary. The process had been working for two years using the Default Frontend connector. Not sure why. The good news is that things are working properly again.