Smarthost TLS problem

Question

I've had a very strange issue today... 
 Our customer has a UTM working as a transparent proxy (https: URL filtering only) in the configuration: LAN -> UTM -> transfer network -> other firewall -> internet 
 The firewall rule on the UTM is Any:Any:Any sincte the other firewall is handling the external traffic. On the UTM the POP3 proxy is active, SMTP proxy is NOT used. 
 Customer has an Exchange 2013 Server that is collecting it's mail with POP-Beamer, using the POP3 Proxy of the UTM. Sending of emails worked via smarthost send connector that used "SMTP (port 25). His mail provider changed his smtp server to SMTP (port 587) and the exchange server stopped sending mails because of certificate validation issues. I found a blog post that was handling the same error message and the author managed to get it up again by enabling netshell winhttp proxy settings. It seemed to have something to do with ocsp verification for the TLS certificate of the new mail server. 
 I tried excluding the exchange server's traffic completely via skip list entry, no luck. What should I say, I gave it a try and set the netshell proxy to use the (transparent) proxy as dedicated proxy and voil&aacute;, the sh..t worked! I'm fine with the "solution" for the moment but there remains a big big question about it... 
 I can't understand why the verification of the TLS certificate doesn't work in transparent proxy mode with a skiplist entry. Can anybody explain this to me?

Stefan G · Accepted Answer

Hi, 
 
 first try to set the SMTP to smtp.ionos.de port 587 
 
 then if this does not work: 
 
 try to install the https://www.telesec.de/de/public-key-infrastruktur/support/root-zertifikate/category/59-t-telesec-globalroot-class-2 
 ROOT Certificate as it got lost by a Windows Server Update on Your Exchange Server. 
 
 MMC on your Exchange 
 Certificate 
 Trusted Root Certificates. 
 
 Restart the Transport Service after that and see the Mails getting send again. 
 
 Thanks to Sebastian Hetzel here - he saved my brain today getting the same errors. 
 
 https://sebastianhetzel.net/exchange-error-454-4-7-5-certificate-validation-failure-ueber-ionos-smarthost/

DouglasFoster · Answer

Coarse language is not motivating. Please write professionally. 
 You said SMTP proxy is off, so it should be no surprise that the SMTP skip list had no effect. SMTP proxy is not intended for authenticated SMTP, and I am doubtful that it could work, especially if encryption is also implemented. It has no effect on POp proxy. 
 Here is my theory: 
 The SMTP change activated encryption for the tirst time.m, so it us encryption that created the problem, not the served name or IP. 
 With POP inspection, UTM connects to the server and the client (Exchange send connector) connects to UTM, which impersonates the remote server using a UTM-generated certificate. 
 With encryoted SMTP, the client connects directly to the remote server and sees the real server certificate. Exchange is apparently clever enough to see that if it gets two very different certificates when only one server is supposed to be involved, then something is amiss. 
 By putting Exchange into proxy mode, both connections are going through UTM and as a result Exchange is happy. 
 Overall, it is a very nonstandard configuration and one should always expect trouble when using three independent products in ways that were unlikely to have been intended or tested during development of any of those products. 
 Winhttp proxy is a pretty hidden feature of Windows. Responding to an explicit proxy request for SMTP client traffic is an apoarently hidden and undocumented feature of UTM. Using Exchange as an email client is a rare implementation of Exchange, even if it is supported. Using traffic filtering between server and client is an unusual configuration for the remote mail server. All of those anomalies are why I do not like the configuration. 
 However, I guess cudos are in order for you, because you found a way to keep the contraption working.