SMTP relay with Client Authentication failing ver 14

[IT247]

We have a hosted 3cx ver 14 instance with a 3rd party provider. We are using an on premise exchange server to relay messages from this instance using client authentication. For over a year this worked, then at some point it quit working. Ver 15 instances using the same exchange server and authentication method are successful.

When sending a welcome email from the ver 14 Instance, 3CX console reports "an exception occurred Error: Server does not support secure connections"

When sending a welcome email from a ver 15 instance to the same server using the same credentials, it delivers the message.

Any help resolving this is appreciated.

 

[Nick W]

TLS change on the Exchange server? Its a guess....

I would look at the exchange server logs and go from there. If nothing changed on the 3CX, then its likely server side patch / update / change.

 

[IT247]

Thanks so much for the reply.

No changes to Exchange server other than Microsoft Updates. ver 15 Instances delivers mail using same exchange server and authentication settings. (User Authentication for SMTP client submission).

SMTP Logs on exchange server show:
:42854,-,,Remote(SocketError) coming from public ip of 3cx instance

 

[Nick W]

The Microsoft updates are where I would be looking.... I am only guessing right now. Does V14 only use older TLS version?

Anyway, I would setup a specific Exchange Receive connector for that server...


Taken from another site:

In Exchange 2013, Log into the ECP > Mail Flow > Receive Connectors. Click the + sign to add a new receive connector. Give it a descriptive name, and choose the Frontend Transport role. Choose the type Custom and click Next. Select the port you wish to listen on - which is usually fine at 25 from all available IPv4. Click Next. Edit the remote IP Addresses listing that is there by default, and add only the IPs or IP range that you wish to use this Receive Connector for. Click on OK, and then Finish.

Select the newly created receive connector and click on the Edit icon. Choose the maximum message size you wish to send out using this receive connector (keep in mind that organizational limits may be more or less and the most restrictive will win). Go to the Security section, and make sure that the only boxes checked off are:

1. Transport Layer Security (TLS)
2. Externally secured (for example, with IPsec)
3. Exchange servers

In the FQDN setting at the bottom, type in your external hostname to access your mail (eg. mail.domain.com). Click Save
Then try using no-authentication from the app. See if that makes a difference.

 

[IT247]

Thanks. I was going to go down that route but didn't want to open the IP up for relay as there are alot of other instances on that ip that I have no control over and feared opening it up to spam.

I suspect it may be trouble negotiating TLS and was hoping somebody could confirm that is an issue w/ ver 14 or point me to some logging or other documentation that would confirm that definitively.

 

[Saqqara]

You should be on version 15.5 sp6 or 16.0.

3cx have made changes to backend ssl certificates and you may have licensing issues

 

[cobaltit]

Thanks. I was going to go down that route but didn't want to open the IP up for relay as there are alot of other instances on that ip that I have no control over and feared opening it up to spam.

I suspect it may be trouble negotiating TLS and was hoping somebody could confirm that is an issue w/ ver 14 or point me to some logging or other documentation that would confirm that definitively.

Can't confirm because I have very few v14 instances left and even less premise-based Exchange environments and I'm glad for both cases .

But yes it sounds like a scoped connector to the IP address is going to be your fix. I really wouldn't worry about spam from that IP. If the provider's systems get compromised to the point where something is able to relay through your environment then you will have bigger issues. Legitimate users on that platform would have to both know your IP AND configure their systems to use/abuse it which seems unlikely.

 

[StefanW]

We have a hosted 3cx ver 14 instance with a 3rd party provider.

As Saqqara already mentioned, I have to urge you to upgrade to v15.5SP at least or even better to v16 as you telephonie service is at risk! Please connect to our customer service team: https://www.3cx.com/contact-form/ if you have a moment!

 

[IT247]

Thanks for all the help. StefanW, can you point me to supporting documentation that the phone service is at risk by running v14? These instances are hosted w/ a 3rd party provider and I want to make them aware and get it upgraded.

Thanks