Yes, you just identified the issue yourself. You'll need both a custom receive connector and a custom send connector, but just for that subnet, not for all of your subnets.
From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On Behalf Of Orlebeck, Geoffrey Sent: Wednesday, March 29, 2017 10:06 AM To: 'exchange@lists.myitforum.com' Subject: [Exchange] RE: Removing Self-Issued Cert: Joseph, thanks for the confirmation, I won't be removing the certificate anytime soon :) Michael, The vendor's error logging shows the self-signed certificate (issuer = EXSRVR1) is the one being presented and that's why it's failing-they don't trust the issuer (EXSRVR1). Also, when you wrote the "last certificate set to use SMTP should be the one that is used", are you referring to when certs were assigned the services? Or are you saying I can specify the order we 'prefer' the certificates be used? I assumed the former, but wasn't sure. One other thing is we have an IPsec VPN between the vendor and our organization to allow traffic to our CAS servers. Would Exchange be seeing this as internal traffic and attempting to respond with the internal certificate because the default Receive Connector encompasses the entire IPv4 address space (0.0.0.0-255.255.255.255)? I'm not sure if best practice is to go back and define all of our internal subnets to remove the "catch all" connector. Thanks, Geoff From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Joseph L. Casale Sent: Tuesday, March 28, 2017 4:42 PM To: 'exchange@lists.myitforum.com' <exchange@lists.myitforum.com<mailto:exchange@lists.myitforum.com>> Subject: [Exchange] RE: Removing Self-Issued Cert: ATTENTION: This email came from an external source. DO NOT open attachments or click on links from unknown senders or unexpected emails. To add a large point to that, the self-signed cert should *not* be removed or you'll break it. I don't know the intimate details however it's my understanding internal servers and consoles etc use this to communicate. I snaped a lab recently and removed it and after a reboot it was awefully broken... From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Michael B. Smith Sent: Tuesday, March 28, 2017 5:28 PM To: exchange@lists.myitforum.com<mailto:exchange@lists.myitforum.com> Subject: [Exchange] RE: Removing Self-Issued Cert: Use openssl to determine what cert is actually being presented. Or turn up logging on the relevant receive and send connectors and examine those logs for the third-party. The LAST certificate set for use by SMTP should be the one that is used, except internally, which should use the internal default certificate. From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Orlebeck, Geoffrey Sent: Tuesday, March 28, 2017 10:24 AM To: 'exchange@lists.myitforum.com' Subject: [Exchange] Removing Self-Issued Cert: We run Exchange 2010 in a two-node DAG. There is a third-party hosted product that we have an IPsec VPN with, but they fail to send email as they do not trust the certificate being presented to them. On each node, there is a self-signed certificate each server has issued to itself (EXSRVR1/EXSRVR2). We have an internal CA and third-party trusted cert set to SMTP services, is there any issue disabling/removing the SMTP service from the self-issued certificates? Looking at this TechNet link https://technet.microsoft.com/en-us/library/dd351257(v=exchg.141).aspx) I can set the assigned services to 'None'. However, I'm curious if there will be any issues from internal Outlook clients using the Root CA certificate for SMTP (since it is trusted across all domain joined devices). Here's a sanitized output of one of our CAS server's certificates: [cid:image001.png@01D2A8AB.67FB1D70] I appreciate any insight. Thank you. -Geoff Confidentiality Notice: This is a transmission from Montage Health. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you.
