Exchange 2010 VS zammad

  • Used Zammad version: 5.1.1 - just upgraded UAT
  • Used Zammad installation type: (source, package, docker-compose, …) package
  • Operating system: Ubuntu 20.0.4
  • Browser + version: latest chrome & or Edge

Expected behavior:

so in our current live environment on version 3.6.X our emails are configured fine and zammad is working like a dream! thats how i would expect it to work in 4.0 and the latest…

Actual behavior:

I’ve tried upgrading to just 4.0 with the same outcome as going, to the very latest, afterwards the emails just don’t work, I’ve removed all the settings and then when I put them back in again I’m getting the error:

SSL_connect returned=1 errno=0 state=error: unsupported protocol

Steps to reproduce the behavior:

re configure emails under channels.

i am quite new to Linux so you will have to bear with me when it comes to your feedback and walking me through things i will try my best :slight_smile:

i cant test it for you on our systems.
But can it be that TLS1.2 isn’t enabled on your exchange2010 server?
i can hardly imagen these days…

Well we are using the same exchange as our live so if that was the case would we not have the same error on our live version :smirk: as far as i know tls is setup on exchange as we have other products that use it.

i can be wrong entirely, but when i read ssl and protocol error, TLS pops up my mind as first.
zammad 3.6 uses ruby in a 2.4.* range if i’m correct, zammad 4 uses 2.6.* and zammad 5 uses 2.7.*,
it can be that during the transistion, default tls1.0 (and maybe tls1.1) are disabled by default and only tls1.2 is allowed. (and SSL v3 should be disabled anyways)

if your server is exposed to the internet (webmail for instance), then use SSLLabs to test used protocols,
if you dont want to, you can use NMAP (.org) with a script setting to test what protocols are enabled.
Try with default 443 for you webmail and you imap(s) port for imap.

nmap -sV --script ssl-enum-ciphers -p 443 <server>

Example output
> nmap -sV --script ssl-enum-ciphers -p 443 Exchange
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-16 09:23 West-Europa (zomertijd)
Nmap scan report for Exchange (192.168.0.1)
Host is up (0.0013s latency).
rDNS record for 192.168.0.1: exchange.local

PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       <snip>
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       <snip>
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       <snip>
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C
MAC Address: xx:xx:xx:xx:xx:xx (Hewlett Packard)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.41 seconds

i’m not totally into zammad and its error codes, it can mean something entirely different, but when you talk ssl and protocol errors this comes into my mind. Windows Server by default (2008 / 2008r2) did only enable sslv3 and tls1.0, where nowadays those should be disabled, and tls1.1 and tls1.2 should be enabled.

Hi thanks for this, I have tried the nmap and I thought it was but it was worth running 1.2 is set this was the output:
443/tcp open ssl/http nginx
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
|
obviously not sharing them on here…
| compressors:
| NULL
| cipher preference: server
|_ least strength: A

Service detection performed. Please report any incorrect results at Nmap OS/Service Fingerprint and Correction Submission Page .
Nmap done: 1 IP address (1 host up) scanned in 13.38 seconds

our network manager thought this was the issue too. but I’m afraid its not the case, this time.

slight note on this nmap test, i see http nginx, is this a proxy or something?
since exchange normally wont work on nginx but on IIS.
Can you also test its imap(s) port(s), because that is probably the place where you get the mail from.
Apart from that my suggestions will run out.

nginx is what zammad uses honestly i don’t really know what its for I just know zammad doesn’t work without it. IIS? we are on a Debian platform that’s a windows package.
I’m using port 25 to connect to the exchange server on the outbound connection, imap if it would work id set it to port 993. but i cant get that far. as it need the outbound connection to work first.

thanks for trying anyway appreciate your help :slight_smile:

To my understanding you tried to fetch mail with channels in zammad.
That failed after your upgrade, even with recreating the e-mail channel.
That produced the ssl error you showed above.

so what you want to test, or what i suggested, not needed but since it looked like the error suggest that.
The connection from your zammad server, to you mail server is not working anymore as supposed to.

Port 25 is indeed used for sending mail, but you state you have problems fetching mail, or atleast i think you did.

Receiving mail based on imap(s), so you need to test that nmap script, from your workstation or zammad server, to the mail server. And preferably the imap(s) port(s) that are in use.
The 443 was an example since that will hit the webmail page, also indicating (but not rule-ing out) some protocol usage.

Ah OK so run it on one server to another that makes sense OK I will do that when I get back leave it with me thanks for your help :slightly_smiling_face:

ok sowhen i ran this
nmap -sV --script ssl-enum-ciphers -p 25 mailservernamehere
ciphers are coming back still on TLSv1.2 but the strength level is coming as F saying its vulnerable to sweet32 attacks doesnt sound good is that what the issue is?

if it returns tls1.2 then i make the assumption that our imap(s) ports are also ok.
cipher != protocol; so i wouldn’t assume it will cause this.

if you run the channel creation wizard on the server, and meanwhile follow / check / tail the production.log, does it output any more data then just the error shown in the web ui?

(i’m out of ideas on this part, and not a zammad engineer, so at somepoint my knowledge stops :frowning: )