SMTP problems with OTRS6 on CentOS 7

[jjurkus]

I have recently updated CentOS 7 to 7.6.1810, and now my SMTP is not working any more.

I was primarily wondering if anybody else has a similar issue? All was working well with OTRS 6.0.15 and a previous version of CentOS 7. Unfortunately I can't roll back the upgrade, and now I'm stuck with a system that can't send out mail.
I'm not certain if it is this configuration or if it has to do with the update.

The log gets filled with errors like this:

Code: Select all

Wed Jan 16 15:41:39 2019 (Europe/Amsterdam) 	error 	OTRS-otrs.Console.pl-Maint::Email::MailQueue-58 	CommunicationLog(ID:42803,AccountType:-,AccountID:-,Direction:Outgoing,Transport:Email,ObjectLogType:Message,ObjectLogID:60119)::Kernel::System::MailQueue => Temporary problem returned from server, requeuing message for sending. Message: SMTPCode: -, ErrorMessage: Can't connect to 10.23.0.4: !
Wed Jan 16 15:41:39 2019 (Europe/Amsterdam) 	error 	OTRS-otrs.Console.pl-Maint::Email::MailQueue-58 	CommunicationLog(ID:42803,AccountType:-,AccountID:-,Direction:Outgoing,Transport:Email,ObjectLogType:Message,ObjectLogID:60119)::Kernel::System::MailQueue => Message could not be sent! Error message: Can't connect to 10.23.0.4: !
Wed Jan 16 15:41:39 2019 (Europe/Amsterdam) 	error 	OTRS-otrs.Console.pl-Maint::Email::MailQueue-58 	CommunicationLog(ID:42803,AccountType:-,AccountID:-,Direction:Outgoing,Transport:Email,ObjectLogType:Message,ObjectLogID:60119)::Kernel::System::Email => Error sending message using backend 'Kernel::System::Email::SMTPTLS'.
Wed Jan 16 15:41:39 2019 (Europe/Amsterdam) 	error 	OTRS-otrs.Console.pl-Maint::Email::MailQueue-58 	CommunicationLog(ID:42803,AccountType:-,AccountID:-,Direction:Outgoing,Transport:Email,ObjectLogType:Connection,ObjectLogID:60126)::Kernel::System::Email::SMTP => Could not connect to host '10.23.0.4'. ErrorMessage: 

Of course I tried the default things: I rebuilt the config, deleted the cache, checked permissions. First used SMTPS, tried SMTPTLS.
I tried the direct IP of the mailserver, DNS name was used previously. The mailserver can be contacted from the host, dns name also resolves correctly. I reinstalled the latest rpm package of OTRS via yum.

If more people have this exact error with the exact combination of OTRS 6 and CentOS 7.6.1810, please let me know.

Also, if you have this exact combination, and it works for you, also let me know. Then I will know it is my setup at fault.

[root]

Hi,

Two thing to check: does SELinux is permanently disabled or did you reboot your system (kernel update?) and it's enabled again? Check with sestatus. Check the connection again, prefered from shell first with telnet/openssl s_client. Often changed IP (DHCP) may break an IP based relaying.

- Roy

[jjurkus]

SELinux is set to permissive, like it always has been since initial install.
The system has been rebooted after the update to load the new kernel.
Also, the mailserver is still resolvable.
I have yet to try to send e-mail from the shell to this mailserver. I'll try that next.

[jjurkus]

It must be someting with the SSL cipher used. This is debug output from davmail (java):

Code: Select all

Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1

I've confirmed this from the OTRS server:

Code: Select all

# openssl s_client -connect win2008r2.gcecad-service.local:587 -tls1 -cipher ECDHE-RSA-AES256-SHA384
CONNECTED(00000003)
140610056091536:error:140830B5:SSL routines:ssl3_client_hello:no ciphers available:s3_clnt.c:832:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1556115045
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Code: Select all

# openssl s_client -connect win2008r2.gcecad-service.local:587 -tls1_2 -cipher ECDHE-RSA-AES256-SHA384
CONNECTED(00000003)
depth=1 C = NL, ST = Zuid-Holland, L = blah, O = blah, CN = blah, emailAddress = ict@blah.nl
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
blahblahblahblah
---
Server certificate
-----BEGIN CERTIFICATE-----
blahblahblahblahblahblahblahblahblah
-----END CERTIFICATE-----
blahblahblah
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3935 bytes and written 303 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-SHA384
    Session-ID: 5CC06E9205A21746FDBDF0C92B25E1A4F4346690A8169A467B93CEA78E5B71C2
    Session-ID-ctx:
    Master-Key: 818EFDBBFA5B270DC1A5681271EAB6D47958FDD736465768AFFB4DA4D6E3D70A35BA4E77CE2AC837ADDA51D2167FE8A9
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1556115090
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
220 DavMail 5.2.0-2961 SMTP ready at Wed Apr 24 16:11:30 CEST 2019

closed

So I think the problem is that with the SMTPTLS backend (needed for the setup here) the mail is sent out via TLS1.0 or TLS1.1 (see the davmail debug log). The tried ciphers are incompatible. If mail was sent using TLS1.2 I think it would work.

I have tried updating IO::Socket::SSL with a newer version, but this does not seem to help. Is there a way to force a TLS1.2 handshake? I've read some things about forcing this in IO::Socket::SSL, but not where and how I can set this.

[jjurkus]

Ugh, I gave up.

I've started using sendmail, and it works again. It doesn't look like it's using encryption, but whatever. Something to fix in the future, if ever.