Re: Missing ciphers after migration

null@example.com (ZhangHuangbin) — Fri, 29 Mar 2024 02:39:46 +0000

Thanks for sharing.

Re: Missing ciphers after migration

null@example.com (bradford) — Thu, 29 Feb 2024 17:48:12 +0000

Actually, Zhang, I think I found the issue and I wouldn't be surprised if other people didn't eventually run into the same problem.

I use certbot to generate Let's Encrypt certificates. After certbot version 2.0.0 the default key type changed from RSA to ECDSA. When I change the key type I am warned that unless you support very old HTTPS clients you should use ECDSA.

I have never had an issue with the certificates using ECDSA until I used them for SMTP, IMAP, and POP, because we do, unfortunately, support older clients.

I have tested generating RSA keys with certbot v2+ and used them on another iredmail server and the ciphers listed by ssl-enum-ciphers includes RSA, so I think it was the LE certificate all along.

Unfortunately due to rate limiting I cannot really know for sure if this resolves the issue on the server I'm having the problem with but I'll report back in a few days with the answer, but I am fairly certain this is the issue.

Anyone using certbot v2+ needs to be aware that their certificates might break compatibility with older devices, despite openssl, postfix, and dovecot configuration.

Re: Missing ciphers after migration

null@example.com (ZhangHuangbin) — Thu, 29 Feb 2024 08:35:44 +0000

Try not to disable TLSv1 and TLSv1 in Postfix parameters:

grep 'TLSv1' /etc/postfix/main.cf

Missing ciphers after migration

null@example.com (bradford) — Thu, 29 Feb 2024 05:30:56 +0000

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.6.8 MARIADB
- Deployed with downloadable installer
- Linux/BSD distribution name and version: Rocky Linux 8 amd64
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Nginx
- Manage mail accounts with iRedAdmin-Pro: Yes
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

I recently did a migration from centos 7 running iredmail 1.6.8 to rocky 8, same version iredmail. After installation available ciphers looked normal, after migration I have a limited number of ciphers. Legacy devices like copy machines and printers can no longer connect to the new iredmail deployment.

Feb 28 19:43:42 mail postfix/submission/smtpd[4925]: SSL_accept error from printer.example.com[10.13.2.57]: -1
Feb 28 19:43:42 mail postfix/submission/smtpd[4925]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:2285:

I've went over postfix configuration and cannot find a configuration causing this behavior. I've checked openssl ciphers using the value from tls_medium_cipherlist and subtracted smtpd_tls_exclude_ciphers and the list is much longer than what I actually get when I run the service and check with nmap ssl-enum-ciphers.

I have all ECDHE ECDSA but I do not have any DHE or RSA which I think is what the legacy devices need.

After the migration and a lot of reading, testing, poking, I decided openssl must be broken and I did the migration again... after a fresh install, postfix configured the same way, I checked ciphers with nmap ssl-enum-ciphers and it looked good. So I completed the migration and BOOM, the problem is back.

Can you think of any other configuration outside of postfix that would cause the issue that I'm describing? OpenSSL supports many ciphers, postfix is configured to use many ciphers, but doesn't?

My main.cf

smtpd_tls_ciphers = medium
tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, 3DES, RC4, MD5, PSK, aECDH, KRB5-DE5, CBC3-SHA

So with the above I check the ciphers:

openssl ciphers -v 'aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!RC4:!MD5:!PSK:!aECDH:!KRB5-DE5:!CBC3-SHA' \
  | awk '/TLSv/{ print $1 }' \
  | sort

I get this list:

AES128-CCM
AES128-CCM8
AES128-GCM-SHA256
AES128-SHA256
AES256-CCM
AES256-CCM8
AES256-GCM-SHA384
AES256-SHA256
ARIA128-GCM-SHA256
ARIA256-GCM-SHA384
CAMELLIA128-SHA256
CAMELLIA256-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-DSS-AES128-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-SHA256
DHE-DSS-ARIA128-GCM-SHA256
DHE-DSS-ARIA256-GCM-SHA384
DHE-DSS-CAMELLIA128-SHA256
DHE-DSS-CAMELLIA256-SHA256
DHE-RSA-AES128-CCM
DHE-RSA-AES128-CCM8
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-CCM
DHE-RSA-AES256-CCM8
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-ARIA128-GCM-SHA256
DHE-RSA-ARIA256-GCM-SHA384
DHE-RSA-CAMELLIA128-SHA256
DHE-RSA-CAMELLIA256-SHA256
DHE-RSA-CHACHA20-POLY1305
ECDHE-ARIA128-GCM-SHA256
ECDHE-ARIA256-GCM-SHA384
ECDHE-ECDSA-AES128-CCM
ECDHE-ECDSA-AES128-CCM8
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-CCM
ECDHE-ECDSA-AES256-CCM8
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-ARIA128-GCM-SHA256
ECDHE-ECDSA-ARIA256-GCM-SHA384
ECDHE-ECDSA-CAMELLIA128-SHA256
ECDHE-ECDSA-CAMELLIA256-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-CAMELLIA128-SHA256
ECDHE-RSA-CAMELLIA256-SHA384
ECDHE-RSA-CHACHA20-POLY1305
TLS_AES_128_CCM_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

But this is what I see on 465, 587:

PORT    STATE SERVICE  VERSION
465/tcp open  ssl/smtp Postfix smtpd
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CCM (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CCM (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|     compressors: 
|       NULL
|     cipher preference: client
|   TLSv1.3: 
|     ciphers: 
|       TLS_AKE_WITH_AES_128_CCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     cipher preference: client
|_  least strength: A

Now, I should mention I also see this same behavior with dovecot, and nginx. It doesn't seem to be an issue with any specific service or configuration. Could iRedAdmin-Pro SQL have anything to do with it? It's one of the components I install last in the migration.

iRedMail — Missing ciphers after migration

Re: Missing ciphers after migration

Re: Missing ciphers after migration

Re: Missing ciphers after migration

Missing ciphers after migration