Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 991
  • Last Modified:

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.
0
hcca
Asked:
hcca
  • 2
1 Solution
 
Todd NelsonSystems EngineerCommented:
Yes, this is the way it is supposed to work.

Have you created custom receive connectors specifically for your scanners and printers? ...

http://exchangeserverpro.com/exchange-2013-configure-smtp-relay-connector/
0
 
hccaAuthor Commented:
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.
0
 
hccaAuthor Commented:
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.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now