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…
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:
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.
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?
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,
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
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)
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?
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…
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.
I still having this issue. 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
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:
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:
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.