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:
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 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 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
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.
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.
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 )
That being said this means you’re tied to the ciphers your OS supports. Ubuntu 20 requires TLSv1.2 and better by default.
Exchange 2010 is old af - you’ll have to tune it’s SSL configuration which may depend on patch level (of Exchange). Exchange is EOL since late 2020 btw…
as far as i know tls is setup on exchange as we have other products that use it.
)