Collabora SSL error

Hi everyone, and Happy New Year!!

I got running Nextcloud server + collabora. The collabora is running on docker on the same server. It was working fine, but since i updated Nextcloud to 16.0.7 (production) and the last collabora docker, I got this error:
cURL error 35: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

My certs are ok, they are the same certs I use with Nextcloud server. They are not selfsigned, they are trusted certs. I am going mad with this, I googleed but can’t find any help with this error. And it is weird, because I got my server running without any errors and suddenly…

Thanks

Googleing and doing some tests, I found that using this command i got this answer:
nmap --script ssl-enum-ciphers -p 443 office.domain.com | grep -E “TLSv|SSLv”
| TLSv1.0:

But if I do the same with my nextcloud server, i got this answer:
nmap --script ssl-enum-ciphers -p 443 nextcloud.domain.com | grep -E “TLSv|SSLv”
| TLSv1.0:
| TLSv1.1:
| TLSv1.2:

I think that the error could be on this TLS difference versions?? My nextcloud and collabora are in the same server and using the same certs

Any help would be apreciated! Thank you!

P.D.
Doing more tests, i got an answer that i can’t understand:

curl -v https://127.0.0.1:9980/hosting/discovery

  • Trying 127.0.0.1…
  • TCP_NODELAY set
  • Connected to 127.0.0.1 (127.0.0.1) port 9980 (#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.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (OUT), TLS alert, Server hello (2):
  • SSL certificate problem: self signed certificate in certificate chain
  • stopped the pause stream!
  • Closing connection 0
    curl: (60) SSL certificate problem: self signed certificate in certificate chain
    More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

With this command, it says that i am using a self signed cert, but i got a trusted cert!!!

your collabora container is using a selfsigned certificate. Your reverse proxy/web server in front of nextcloud may use a trusted cert.
P.S.: you’ll never get a trusted cert for 127.0.0.1. I think that might be a kind of security armageddone.

and i think it’s normal to use a selfsigned cert for colabora container because they use the -k aka --insecure option of curl on there website: https://www.collaboraoffice.com/code/docker/

grafik

what did you curl? or where did you get this error message?

Ok, now I understand, one thing is the certs I used to connect to my site, and other thing the certs than docker uses for itself.
So the error I am getting with curl (cURL error 35: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure) when I try to open a document with collabora, can be with the certs of my reverse proxy?

Thanks a lot!!!

well. I saw this error before. but don’t remember where and when. (of course in the context of nc/collabora. it was during writing/testing my playbooks. but i can’t rememeber what caused it and how i solved it.)

so.

are you using apache or nginx? nextcloud also running as docker image?

Hi reiner,
My nextcloud server is a lamp server on an ubuntu 18.04 (originally it was an owncloud server, version 7) , and collabora is running on a docker on the server. I will take a look on your playbooks and try to google a little more,

thank you!

i would suggest to look into the apache conf files and the ssl settings there.

Sorry for the delay in the answer.

I look my conf files at apache, and they are pointing to the same certificate files… If you want, I can put the conf files to take a look, 4 eyes are better than 2 in this cases, you know :crazy_face::crazy_face:

Thanks a lot for your time!!!

Hello,

I found this tool to test the ciphers that uses my server:

When I run ./testssl.sh -e office.pointing.url, i got this:
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC)

x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA
x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA
x0a DES-CBC3-SHA RSA 3DES 168 TLS_RSA_WITH_3DES_EDE_CBC_SHA

but running same command to my nextcloud install, I got this:

Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC)

x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384
x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256
xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
xc028 ECDHE-RSA-AES256-SHA384 ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
x9f DHE-RSA-AES256-GCM-SHA384 DH 4096 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 521 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
xccaa DHE-RSA-CHACHA20-POLY1305 DH 4096 ChaCha20 256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
xc0a3 DHE-RSA-AES256-CCM8 DH 4096 AESCCM8 256 TLS_DHE_RSA_WITH_AES_256_CCM_8
xc09f DHE-RSA-AES256-CCM DH 4096 AESCCM 256 TLS_DHE_RSA_WITH_AES_256_CCM
x6b DHE-RSA-AES256-SHA256 DH 4096 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
x39 DHE-RSA-AES256-SHA DH 4096 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
xc077 ECDHE-RSA-CAMELLIA256-SHA384 ECDH 521 Camellia 256 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
xc4 DHE-RSA-CAMELLIA256-SHA256 DH 4096 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
x88 DHE-RSA-CAMELLIA256-SHA DH 4096 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384
xc0a1 AES256-CCM8 RSA AESCCM8 256 TLS_RSA_WITH_AES_256_CCM_8
xc09d AES256-CCM RSA AESCCM 256 TLS_RSA_WITH_AES_256_CCM
x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256
x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA
xc0 CAMELLIA256-SHA256 RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
xc051 ARIA256-GCM-SHA384 RSA ARIAGCM 256 TLS_RSA_WITH_ARIA_256_GCM_SHA384
xc053 DHE-RSA-ARIA256-GCM-SHA384 DH 4096 ARIAGCM 256 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384
xc061 ECDHE-ARIA256-GCM-SHA384 ECDH 521 ARIAGCM 256 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384
x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256
xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
xc027 ECDHE-RSA-AES128-SHA256 ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
x9e DHE-RSA-AES128-GCM-SHA256 DH 4096 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
xc0a2 DHE-RSA-AES128-CCM8 DH 4096 AESCCM8 128 TLS_DHE_RSA_WITH_AES_128_CCM_8
xc09e DHE-RSA-AES128-CCM DH 4096 AESCCM 128 TLS_DHE_RSA_WITH_AES_128_CCM
xc0a0 AES128-CCM8 RSA AESCCM8 128 TLS_RSA_WITH_AES_128_CCM_8
xc09c AES128-CCM RSA AESCCM 128 TLS_RSA_WITH_AES_128_CCM
x67 DHE-RSA-AES128-SHA256 DH 4096 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
x33 DHE-RSA-AES128-SHA DH 4096 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
xc076 ECDHE-RSA-CAMELLIA128-SHA256 ECDH 521 Camellia 128 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
xbe DHE-RSA-CAMELLIA128-SHA256 DH 4096 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
x45 DHE-RSA-CAMELLIA128-SHA DH 4096 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256
x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256
x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA
xba CAMELLIA128-SHA256 RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
xc050 ARIA128-GCM-SHA256 RSA ARIAGCM 128 TLS_RSA_WITH_ARIA_128_GCM_SHA256
xc052 DHE-RSA-ARIA128-GCM-SHA256 DH 4096 ARIAGCM 128 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256
xc060 ECDHE-ARIA128-GCM-SHA256 ECDH 521 ARIAGCM 128 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256

I don’t know if this could help. I am really lost with this issue, because all was running a few weeks ago and suddenly i got this error. More and less it coincides in time with the last upgrade of nextcloud server in production mode.

P.D. Thinking on this, I got UFW running on my server, could be something related with this?

It might be related with your server setup.
You said in the beginning, that office.domain.com is only able to use TLSv1?
So this is a protocol that every new application/server/service will refuse, because it is declared as unsafe. With every update the number will go up, so at the moment TLSv1.2 is recommended and TLSv1.1 is allowed. Next will be TLSv1.3 recommended and TLSv1.1 forbidden.
So look for the definitions in your webserver(s)

After doing some work, I can say that my error comes from my apache config. I don’t know where, I think is something related with de reverse proxy, but I am complete lost with this… Any ideas where to start looking?

Thanks a lot !!!

Just a wild guess - do you use letsencrypt?
With the setup letsencrpyt setup they install an additional setup file which is included at the bottom of the ssl config for the virtual host - I had a similar problem with that

No, I use trusted certificates. I will take a look to them, perhaps I added those lines and I don’t need them. The craziest thing is that I got it working the servers until one month ago…

Thanks :wink:

Hi again!

After doing some more work, I think that the error probably comes from CURL or OPENSSL versions… It’s the only explanation I can found. I had take a look to all my config files, my certificates, etc and all it’s ok. I will try to downgrade Curl and openssl, perhaps this could help. If it works, I will post it.

Thanks

I still having this issue. :pleading_face: I found a little configuration mistake at the start of my collabora config file at apache, now all debug messages are for collabora are ok. But cURL still giving me the same error.
Thanks for your answers and suggestions!!

P.D. Finally I found something!! I don’t know why, but if I add to my /etc/hosts file the line
127.0.0.1 office.web.org
The error dissapears. I can’t still open the documents, it gives me a blank page, but now I don’t have the cURL error

How is your loolwsd.xml - did you change something?

I don’t think so, I got collabora running on a docker and I followed the official installation guide.

Where can I find it?

docker cp -a mycollab_instance:/etc/loolwsd/loolwsd.xml loolwsd.xml_${DATEofTODAY}

Then you can edit it and copy back - but dont forget to change the owner, or else the container will reboot endlessly, because it can not read the file:

docker cp -a loolwsd.xml_${DATEofTODAY} mycollab_instance:/etc/loolwsd/loolwsd.xml \
docker exec -it mycollab_instance chown -R lool:lool /etc/loolwsd/loolwsd.xml

Have you configured SSL ecdh curves in your webserver?

I also had the issue that with the latest Collabora docker container version I wasn’t able to open any document. docker logs <container name> gave me some errors regarding SSL.

I found out that my configuration of ecdh curves was the cause of the problem (I’m using nginx).
I had this one (always worked until now):

ssl_ecdh_curve secp521r1:secp384r1;

Now I’ve switched to this one as Collabora seems to need prime256v1:

ssl_ecdh_curve secp521r1:secp384r1:prime256v1;

Maybe this is somehow related to your problem.