SMTP Authentication Issues - Forced SSLv3

Note: your system will not allow the posting of links, yet you specifically asked to post thing using gist.

Steps to reproduce

  1. install current version of ownCloud onto OracleLinux 8.6 server following this guide: www dot linode dot com /docs/guides/install-and-configure-owncloud-on-centos-stream-8/
  2. verify users can login and access site
  3. attempt to configure email settings to connect with Exchange 2019 on premise server using following settings:
  • send mode = smtp
  • encryption = ssl/tls
  • from address = EMAIL (Note: this is a working account)
  • Authentication method = Login && Plain (Note: both settings have been attempted)
  • Authentication required = checked
  • Server address = DOMAIN
  • Port = 587
  • Credentials = EMAIL && password

Expected behaviour

A test email should be sent

Actual behaviour

The following error is received : A problem occurred while sending the email. Please revise your settings. (Error: Connection could not be established with host DOMAIN :stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:1408F10B:SSL routines:ssl3_get_record:wrong version number)

Server configuration

Operating system:
NAME=“Oracle Linux Server”
PRETTY_NAME=“Oracle Linux Server 8.7”
HOME_URL=“linux dot oracle dot com”
BUG_REPORT_URL=“bugzilla dot oracle dot com”


Web server:
Server version: Apache/2.4.37 (Oracle Linux)
Server built: Oct 3 2022 05:16:06

| Variable_name | Value |
| admin_tls_version | TLSv1.2,TLSv1.3 |
| immediate_server_version | 999999 |
| innodb_version | 8.0.30-22 |
| original_server_version | 999999 |
| protocol_version | 10 |
| replica_type_conversions | |
| slave_type_conversions | |
| tls_version | TLSv1.2,TLSv1.3 |
| version | 8.0.30-22 |
| version_comment | Percona Server (GPL), Release 22, Revision 7e301439b65 |
| version_compile_machine | x86_64 |
| version_compile_os | Linux |
| version_compile_zlib | 1.2.12 |
| version_suffix |

Please note: Percona is a bug for bug of mysql with enterprise features such as clustering, encryption, and rotating keys.

PHP version:
PHP 7.4.30 (cli) (built: Jun 7 2022 08:38:19) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.30, Copyright (c), by Zend Technologies

ownCloud version: (see ownCloud admin page)

installed 1
versionstring 10.11.0
edition Community
productname NGRSDSS
product NGRSDSS
hostname DOMAIN

Updated from an older ownCloud or fresh install:
Fresh Install

Where did you install ownCloud from:
download dot owncloud dot com /server/stable/

Signing status (ownCloud 9.0 and above):
No errors have been found.

The content of config/config.php:
gist dot github dot com/jasonmacer/e4688725179b9ed3e3e3b69fa4af3264

List of activated apps:
gist dot github dot com/jasonmacer/9ea5c61b84777d6c432a068f6254bbff

Are you using external storage, if yes which one: local/smb/sftp/…

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…
LDAP/Active Directory

LDAP configuration (delete this part if not used)

gist dot github dot com/jasonmacer/28ba41771feed3910d90500b78a020d7

Client configuration

Chrome && Brave && Edge

Operating system:


Web server error log

gist dot github dot com/jasonmacer/64215e4728e76ff168b2ede4cd064f34

ownCloud log (data/owncloud.log)

gist dot github dot com/jasonmacer/4fddf8e54585c4569c40566b9e54a9ca

Browser log

  • gist dot github dot com/jasonmacer/32a0a966da86d1b55aba1273ae2631d3
  • JavaScript console shows no events

This sounds like a system or infrastructure issue, rather than anything ownCloud specific. I would test with openssl s_client from the Oracle server command line. The following articles may be helpful if you are unfamiliar with this technique.

Thanks for those links!

i am able to connect, but get a responder of 250 XRDST and cannot perform ehlo and further operations.

That said I do get a verification err: self signed certificate on the verify return code: 18.

This is an exchange 2019 on premise server that I am connecting to, however what i’m looking at is the server is trying to only send out on tls1.3 however, exchange will only accept 1.2, as even on Server 2022 (which supports 1.3) exchange does not.

I just didn’t know if there was a way for the swiftmail or symfony mailer to limit to 1.2 when trying the connection.

I will keep on digging into this.

I think I found your problem. You need to use STARTTLS when using the submission port on 587. You are using SSL/TLS. Try changing that and let us know if that fixes your issue.

So,that time I did receive a new error: A problem occurred while sending the email. Please revise your settings. (Error: Unable to connect with TLS encryption)

I’m still somewhat convinced it’s due to TLS 1.3 vs exchange limited 1.2.

I do have smtp debug set to true, but where are those log files stored?

I am not convinced of this. If TLS 1.3 negotiation is unsuccessful, TLS 1.2 should be attempted automatically unless you have somehow explicitly disallowed it. The inability to complete an SMTP transaction using openssl s_client strikes me as more relevant. That self-signed cert may be part of your problem. Symfony Mailer documentation indicates that can be a problem.

Alas, I don’t know. I have never needed to enable them. If it is an ownCloud setting, you might check the ownCloud log.

While i do agree 1.2 should be attempted, for some reason the server is forcing 1.3. While i am running Oracle Linux 8.7 which is bug for bug of RHEL 8.7.

An interesting fact is that I’ve disabled ALL TLS but 1.2 in apaches ssl.conf. However, even after a reboot the system is still defaulting to TLS 1.3 with apache. This leads me to still looking at the 1.3 being forced on the remote app side.

I had some meetings, but I’m now back and getting back to digging

Apache TLS settings only factor into connections that you make to the web server and have nothing to do with the TLS version chosen by an outgoing connection initiated by a PHP application.

No reboot should be necessary to apply changes to your Apache webserver TLS settings. A simple reload from systemctl after the edit should suffice. My initial hunch is that you are editing a different file than the one being applied into your interpreted configuration. None of that should have any relevance though for reasons already stated.

I am not sure what you are calling the remote app side. I would interpret that as your Exchange server, which you previously indicated is incapable of using TLS 1.3, making that an odd place to expect TLS 1.3 to be forced.

Good luck and let us know if you find anything that fixes it.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.