Cant send mail due to TLSV1?

Hello, I arrive to this community (I didnt know about it), from github where I reported a bug but I got notified that is not a bug but something wrong within the configuration. Maybe here someone can help me?

Bug description
I cant send emails from nextcloud from mail app. Test email doesnt work either.

In the Nextcloud server cloud.mydomain
The error when I click “Send email” in email server: A problem occurred while sending the email. Please revise your settings. (Error: Connection could not be established with host :stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed)

Everything else in Nextcloud works besides email service.
The error is present since the fresh install of Nextcloud 22.1.1. but I didnt have the time to find a solution.

In the email server mail.mydomain
I get the following log in Postfix:
warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:…/ssl/record/rec_layer_s3.c:1544:SSL alert number 48:

Steps to reproduce

  1. Send mode SMTP; Encrypthon SSL/TLS; Authentication method “Login”; Authentication required. Set the other email address and credentials information.
  2. is a different server running mailcow mailserver. There is a third server with a CRM service that can send and receive emails through with SMPT mode.
  3. Nextcloud is only service in cloud.mydomain server with FQDN “server2.mydomain” and IP
  4. Nextcloud server is running behind apache and signed with Letsencrypt certificates
  5. Nextcloud server is running behind Cloudflare service with proxied DNS

Enviroment: manual install in Ubuntu server 20.04 LTS


TLS v 1 is outdated and should be used any longer.
Try to use 1.2 or 1.3.

I edited the title and the message because I could narrow the issue to the TLSv1 certificate. My mail server is only accepting TLSv1.2 and TLSv1.3

I also saw that the mailserver gives this info: SSL_accept error from unknown[]: -1

Basically I think that Nextcloud is not using a valid TLS version or SSL protocol

But I am not using it, I never was (at least not willingly)

This is the SSL part of the conf of apache:

SSLEngine on
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCompression off
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/

I just disabled DNS for the nextcloud server in Cloudflare to make a test through ssllabs and this is the result related to the protocols:

TLS 1.3 Yes
TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3 No
SSL 2 No

I truly dont understand then

This has nothing to do with your nextcloud server, rather with your mail server:

You have to test with ssllabst and disable TLS 1 there.

Thanks for the help :slight_smile: has TLSv1 disables already. I just checked the nginx conf (this server I have running behind nginx) and also in sslabs

sslabs report related to protocols of

TLS 1.3 Yes
TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3 No
SSL 2 No

1 Like

UPDATE: Add Email Port also, I suppose it is different from 443.

Its getting more interesting. Do you have ssh access to your nextcloud server? Try to check with curl from the nextcloud machine what is happening there. E.g.:

curl -v

Do you see Ciphers and Valid Certificate? If connection is dropped because of certificate error, add -k key to ignore Certificate and see output.

Example for google:

You can try to “force” curl to use some protocols, or even ciphers, e.g.:

curl -v --tlsv1.3 --tls-max 1.3 https://..
# or for 1.0 if supported by curl for you
curl -v --tlsv1.0 --tls-max 1.0 https://..

As alternative you can use this script from the Nextcloud Server to see Ciphers. But this will even not test TLS 1.0 / SSL 3.0, because it is out of support and usually you have to compile your own OpenSSL with this support.

You don’t want to test the https:// interface of your web server but the MTA - which is bound to SMTP SSL/TLS port and best tested using openssl s_client -connect mailserver.domain:465 or if you want to test specific TLS version:

#TLS 1.0
openssl s_client -tls1 -connect mailserver.domain:465
#TLS 1.3
openssl s_client -tls1_3 -connect mailserver.domain:465

add -debug to see more output…

curl -v -k

*   Trying
* Connected to ( port 465 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=DE; ST=NRW; L=Willich; O=mailcow; OU=mailcow;
*  start date: Sep 19 09:01:37 2021 GMT
*  expire date: Sep 19 09:01:37 2022 GMT
*  issuer: C=DE; ST=NRW; L=Willich; O=mailcow; OU=mailcow;
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> Host:
> User-Agent: curl/7.68.0
> Accept: */*
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Received HTTP/0.9 when not allowed

* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (1) Received HTTP/0.9 when not allowed

Meanwhile in the mailserver, the log showed:

  • Anonymous TLS connection established from unknown[]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
  • warning: non-SMTP command from unknown[]: GET / HTTP/1.1

My opinion is that the mailserver log is normal but the interesting thing is that if I use curl -v (without -k) then the log from the mail server outputs:

  • warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:…/ssl/record/rec_layer_s3.c:1544:SSL alert number 48:

And that is exactly the same warning I get when trying to send the test email through Nextcloud

Note that is the nextcloud server IP and is the mail server IP

1 Like

The output of openssl s_client -connect

depth=0 C = DE, ST = NRW, L = Willich, O = mailcow, OU = mailcow, CN =
verify error:num=18:self signed certificate
verify return:1
depth=0 C = DE, ST = NRW, L = Willich, O = mailcow, OU = mailcow, CN =
verify return:1
Certificate chain
 0 s:C = DE, ST = NRW, L = Willich, O = mailcow, OU = mailcow, CN =
   i:C = DE, ST = NRW, L = Willich, O = mailcow, OU = mailcow, CN =
Server certificate
The certificate
subject=C = DE, ST = NRW, L = Willich, O = mailcow, OU = mailcow, CN =

issuer=C = DE, ST = NRW, L = Willich, O = mailcow, OU = mailcow, CN =

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
SSL handshake has read 2283 bytes and written 389 bytes
Verification error: self signed certificate
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
Post-Handshake New Session Ticket arrived:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 31786BFF4AF93D440A9C0F1712DBB4A936B56D05AF66F600C7AE74A6F65EB72A
    Resumption PSK: 4F8AC71917E2D334D1BA7E85BEAE149C10FF3C394C8DA0CAC8FFD6883B567329DCEBC5AAFA32B3117B44991A739DDE93
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 46 d3 99 7f 0e a1 05 4c-cf 88 32 c3 6f fb 59 31   F......L..2.o.Y1
    0010 - 67 a4 ca 80 79 d7 36 58-77 83 8d ab 38 27 ef 0e   g...y.6Xw...8'..
    0020 - 41 f8 9d 73 c6 ea 7b 57-cd 51 26 1d 42 a4 b9 37   A..s..{W.Q&.B..7
    0030 - 7a e5 18 d6 6c 18 bb 13-73 b8 1d a6 14 e4 82 51   z...l...s......Q
    0040 - 5b b4 11 4b 9f ca 84 be-e7 85 16 a0 07 46 b7 fd   [..K.........F..
    0050 - e9 2e 44 13 b3 72 ab df-76 3f dd b2 a9 58 65 1b   ..D..r..v?...Xe.
    0060 - cd 85 a2 20 d7 11 64 ff-b5 4d 49 8f 4a eb 4d 67   ... ..d..MI.J.Mg
    0070 - ee 7f f0 04 8d c8 db 92-4c da ad 47 a1 be 99 c6   ........L..G....
    0080 - c3 a7 c9 73 c5 94 04 9c-fb 47 e1 a4 23 7f ad 3c   ...s.....G..#..<
    0090 - 3e 8e 96 9a 37 b0 f6 d7-51 be cd 80 1b 42 7c 40   >...7...Q....B|@
    00a0 - ce 5b b7 a0 b8 7f 7b 23-ef e3 c9 1a 7e 38 0d 30   .[....{#....~8.0
    00b0 - 1e af e8 34 68 fc d4 f2-cf db 97 ed af e9 b8 ad   ...4h...........
    00c0 - 95 4d cf 33 b0 84 85 45-2a 06 2a 3d f4 4c 79 48   .M.3...E*.*=.LyH

    Start Time: 1646061655
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
    Extended master secret: no
    Max Early Data: 0
read R BLOCK
220 ESMTP Postcow

I presume the error is here:

most likely Nextcloud mail client stops here. There is no good way to make server software trust self-signed certificates (neither if you have more than just few clients) - I would recommend you to issue valid public TLS certificate for your mail server.

1 Like

You see, curl is also good for any connection test, also SMTP :smiley:

1 Like

In this server, as well as in other servers, I am using Letsencrypt cerbot certificates, isnt that good enough?

Other server, different from Nextcloud, lets call it uses the same mail server to send emails through SMTP. Its certificate is also signed with Letsencrypt cerbot certificate and it can send emails withouth issues.

the problem is not the sending device - (in this case acting as client) it doesn’t need any TLS cert, the problem is your mailcow certificate:

which is self-signed and not issues by letsencrypt or any other well-known CA.

I am sorry, maybe its too many hours in front of this issue without success but my just exploded and Im going to ask something that doesn’t make sense. How can it be self-signed if it is issued by letsencrypt?

He is from ssllabs report of the mail server:

Valid from Fri, 28 Jan 2022 22:47:53 UTC
Valid until Thu, 28 Apr 2022 22:47:52 UTC (expires in 2 months)
Key RSA 2048 bits (e 65537)
Weak key (Debian) No
Issuer R3
Signature algorithm SHA256withRSA
Extended Validation No
Certificate Transparency Yes (certificate)
OCSP Must Staple No
Revocation information OCSP
Revocation status Good (not revoked)
Trusted Yes
Mozilla Apple Android Java Windows

If I check manually the locker on the browser search tab, everything seems fine and it also says that its R3 certificate issued by Letsencrypt

In ssllabs report I found something that I didn’t understand in “certification paths” the last line says this:
In trust store
DST Root CA X3 Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
Weak or insecure signature, but no impact on root certificate

I have no idea what is this or how to find it within the server. I know this is not related to Nextcloud but do you have any hint about it?


the cert we are talking about is not issued by letsencrypt:

the tests you do with browser and ssllabs check the web interface of your mail server but not the SMTP receive interface (which you check with curl/openssl command above with port :465). Please check the docs from mailcow how tho configure SMTP server certificate or send mails from Nextcloud without TLS (if both are in same networks it’s secure enough)…