Collabora nearly works on another http server. Error : SSL/TLS traffic on plain http port

Server
1

Steps to reproduce

  1. Run owncloud, click Office (collabora app)
  2. Can see office files (so app and collabora server working) but clicking on anyone seems to spin forever, no result.
  3. owncloud works fine and collabora server seems to be working OK - admin console is accessible and daemon working.

Expected behaviour

Tell us what should happen

I’d expect collabora or owncloud to open the file or produce error.

Actual behaviour

Tell us what happens instead

Spinning icon appears and stays, no screen error.

Error in collabora server shows :
[ websrv_poll ] ERR Looks like SSL/TLS traffic on plain http port| wsd/LOOLWSD.cpp:2031

Couldn’t find error in owncloud log.

Server configuration

Operating system:
Owncloud on Raspbian server, 4.15.0-52-generic

Web server:
apache2.4.25 raspbian running https:// self host domain with /owncloud
Database:
Mariadb 10.1
PHP version:
5.6.33
ownCloud version: (see ownCloud admin page)
10.0.3
Updated from an older ownCloud or fresh install:
updated many time over several years

I’ve followed the collabora instruction (https://www.collaboraoffice.com/code/#getting_set_up) for installing on CODE onto separate ubuntu 18.04 server as package and then setting apache reverse proxy BUT with “SSL terminates at the proxy” option.

I’ve used reverseproxy to http on this server for other applications without issues.

It seems however that mixing http (collabora) / https (owncloud) causes an error.

Could somebody confirm this and if there is a fix, otherwise I’ll try https on both sides (not preferred option)?

Thanks,
Andrew

2

Partially answering my own question -

Assuming the basic conflict of an owncloud server using https and a collabora using http is at fault I remove collabora and replaced it with the docker version that includes https / SSL setup.

BUT I still get errors:-

Owncloud reports :
The exact error message was: cURL error 7: Failed to connect to acer.home port 9980: Connection refused

  • tried adding collabora to /etc/hosts
  • adding docker to UFW

Collabora reports:
ab@acer:~$ curl -vkI --http1.1 https://127.0.0.1:9980

  • Rebuilt URL to: https://127.0.0.1:9980/
  • Trying 127.0.0.1…
  • TCP_NODELAY set
  • Connected to 127.0.0.1 (127.0.0.1) port 9980 (#0)
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • (304) (OUT), TLS handshake, Client hello (1):
  • OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 127.0.0.1:9980
  • tried downgrade to collabora/code 4.0
  • various tweaks to loolwsd.xml inside docker container

Since this is apparently not an owncloud , (nextcloud have similar problems) issue I’m moving to collabora site

1 Like
3

Could anyone assist here?

I tried again using my original collabora docker setup without SSL, all runs smoothly, I can access the http://192.168.1.106:9980/loleaflet/dist/admin/admin.html etc.

When I go to my https://owncloud I can see thumbnail documents but when I try to open I see this error with extracts in the collabora server logs :

[ websrv_poll ] DBG HTTP request: /| wsd/LOOLWSD.cpp:2206
[ websrv_poll ] WRN client - server version mismatch, disabling browser cache.| wsd/FileServer.cpp:279
[ loolwsd ] WRN SSL support: SSL is disabled.| wsd/LOOLWSD.cpp:1007
[ websrv_poll ] ERR Looks like SSL/TLS traffic on plain http port| wsd/LOOLWSD.cpp:2041

To clarify servers on same LAN, owncloud has FQDN, apache reverse proxy to http://192.168.1.106 where docker runs.

Any guidance would be greatly appreciated.

4

Well, despite lack of feedback I finally had some success using Eolie browser in Ubuntu, but Firefox, Midori and android chrome has SSL errors repored in docker as :-

wsd-00021-00030 2019-08-11 21:59:58.609223 [ websrv_poll ] ERR > Error while handling poll for socket #16 in websrv_poll: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown| ./net/Socket.hpp:570

wsd-00021-00030 2019-08-11 22:03:12.614629 [ websrv_poll ] ERR Socket #16 SSL error: SYSCALL (5). (ECONNRESET: Connection reset by peer)| ./net/SslSocket.hpp:236
wsd-00021-00030 2019-08-11 22:03:12.615512 [ websrv_poll ] ERR Socket #16 SSL BIO error: error:140940E5:SSL routines:ssl3_read_bytes:ssl handshake failure (0: Success)| ./net/SslSocket.hpp:281
wsd-00021-00030 2019-08-11 22:03:12.616284 [ websrv_poll ] ERR Error while handling poll for socket #16 in websrv_poll: error:140940E5:SSL routines:ssl3_read_bytes:ssl handshake failure| ./net/Socket.hpp:570

To get this far I adjusted the above settings as follows :-

  1. Seems OC and Collabora CODE docker will only work in reverse proxy across a LAN using HTTPS to HTTPS so setup with SSL both sides.

  2. I created a SSL certificate in docker which was finally accepted by OC after a lot of tweaking like CN different on root CA and cert.

  3. So I can’t ask users only to Eolie, any inputs welcomed.

1 Like
5

This is correct, if you’re using https on ownCloud you must use collabora with https as well.

Which docker version? This one?

I would suspect that this is a security issue within Eolie and will get fixed at some point. So it doesn’t seem like a solution at all.

I don’t think I fully understand your setup yet. So you’re running ownCloud on an RPi.
Is this also your docker0 for running the Collabora container?
Where is the reverse proxy running?

Have you tried setting up Collabora with SSL, and then importing that certificate (I assume it is self-signed) into ownCloud using occ security:certificates:import?

1 Like
6

Thanks for your response eneubauer. While I’m trying to debug this it really helps to verify some of the issues with somebody else.

Currently I think its an apache2 reverse proxy issue and/or self-signed certificate and not OC / Callabora.

First to respond to your questions.

a. Yes, I’m using that collabora/code docker adapted with my own docker file/image so I could play with just the self-signed certificates/loolwsd.xml

b. OK for Eoile, but in firefox I found if I logged into https://192.168.1.105:9980/loleaflet/dist/admin/admin.html and accepted the risk/certificate, then everythiong works.

c. my HW setup remains same as originally reported except I updated

Server configuration

Operating system :
Owncloud on Raspbian server, 4.15.0-52-generic
Web server:
apache2.4.25 raspbian running https:// self host domain with /owncloud
Database:
Mariadb 10.1
PHP version:
7.2
ownCloud version: (see ownCloud admin page)
10.2.1

  • reverse-proxy is running from here

collabora/docker 19.03.1 on Ubuntu 19.04 host in same LAN as OC server

I’ve tried importing the self-signed certificates like this, both seems to work:-

pi@raspberrypi3:~ $ sudo -u www-data php occ security:certificates:import ~/ca-chain.cert.pem

sudo cat ca-bundle.crt >> /var/www/html/owncloud/resources/config/ca-bundle.crt

So nearly everything works :

  • I can go to OC, see the Office tab, see thumbnails(large) of files.
  • From LAN I can go to /loleaflet/dist/admin/admin.htm and see server stuff
  • I’ve edited/created files on one machine/user and verified on another (after accepting risk/certificate within the browser).

BUT, if I click any office file in new browser , it gets stuck (spinning disc) and I get see docker error logs like this:-

wsd-00021-00030 2019-08-12 09:51:34.305399 [ websrv_poll ] ERR Error while handling poll for socket #22 in websrv_poll: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request| ./net/Socket.hpp:570
wsd-00021-00030 2019-08-12 09:52:47.934890 [ websrv_poll ] ERR Socket #22 SSL BIO error: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca (0: Success)| ./net/SslSocket.hpp:281
wsd-00021-00030 2019-08-12 09:52:47.935002 [ websrv_poll ] ERR Error while handling poll for socket #22 in websrv_poll: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca| ./net/Socket.hpp:570

The ‘unknown ca’ is expected I suppose but I’ve added some lines to the apache2 setup that should prevent this i.e. SSLProxyMachineCertificateChainFile):-

<VirtualHost *:443>
ServerName awsbarker.ddns.net
Options -Indexes

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/awsbarker.ddns.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/awsbarker.ddns.net/privkey.pem
#SSLProxyCACertificateFile /var/www/html/owncloud/resources/config/ca-bundle.crt
SSLProxyMachineCertificateChainFile /var/www/html/owncloud/resources/config/ca-bundle.crt

SSLProtocol all +TLSv1 +TLSv1.1 +TLSv1.2
SSLProxyProtocol +TLSv1 +TLSv1.1 +TLSv1.2

SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on

Include /etc/letsencrypt/options-ssl-apache.conf

Encoded slashes need to be allowed #NoDecode

AllowEncodedSlashes NoDecode

Container uses a unique non-signed certificate

SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
SSLProxyCheckPeerExpire Off

keep the host

ProxyPreserveHost On
ProxyRequests Off

Disable caching

Header set Cache-Control “no-cache, must-revalidate, private”

Enable X-XSS-Protection

Header set X-XSS-Protection: “1; mode=block”

static html, js, images, etc. served from loolwsd

loleaflet is the client part of Collabora Online

ProxyPass /loleaflet https://192.168.1.105:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://192.168.1.105:9980/loleaflet

WOPI discovery URL

ProxyPass /hosting/discovery https://192.168.1.105:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery https://192.168.1.105:9980/hosting/discovery

Capabilities

ProxyPass /hosting/capabilities https://192.168.1.105:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities https://192.168.1.105:9980/hosting/capabilities

Main websocket

ProxyPassMatch “/lool/(.*)/ws$” wss://192.168.1.105:9980/lool/$1/ws nocanon

Admin Console websocket

ProxyPass /lool/adminws wss://192.168.1.105:9980/lool/adminws

Download as, Fullscreen presentation and Image upload operations

ProxyPass /lool https://192.168.1.105:9980/lool
ProxyPassReverse /lool https://192.168.1.105:9980/lool

BrowserMatch “MSIE [2-6]”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0

MSIE 7 and newer should be able to use keepalive

BrowserMatch “MSIE [17-9]” ssl-unclean-shutdown

So, as I mention it appears to be apache issue rather than OC/collabora.
I suppose allowing reverse-proxy to do it’s work and allow OC to work with https/http would resolve this - but I’m not expert on this for sure!

Thanks for any further insight.

PS I also noticed OC occ reports a wrong valid date on the cert:-

pi@raspberrypi3:/var/www/html/owncloud $ sudo -u www-data php occ security:certificates
±------------------±----------------±----------------±------------------±----------------+
| File Name | Common Name | Organization | Valid Until | Issued By |
±------------------±----------------±----------------±------------------±----------------+
| ca-chain.cert.pem | Dummy Authority | Dummy Authority | December 31, 1969 | Dummy Authority |
±------------------±----------------±----------------±------------------±----------------+

pi@raspberrypi3:/var/www/html/owncloud $ openssl x509 -noout -text -in ~/ca-chain.cert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ef:29:1f:81:c5:0e:37:84
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CH, ST=BW, L=ecublens, O=Dummy Authority, CN=Dummy Authority
Validity
Not Before: Aug 11 14:12:43 2019 GMT
Not After : Aug 10 14:12:43 2044 GMT

7

SOLVED and working nicely.

After trying all combinations I could dream of using self-signed certs and reverse-proxies I finally got this working by using a new certbot certificate for a separate domain and using that on the docker server.

I suppose this is how it should be in production between two physically separated servers but I still don’t get why an apache reverse-proxy to same LAN server with self-signed certificate couldn’t work.

1 Like