Office gives WOPI error

Issue:
Upon opening a document Office gives “Unauthorized WOPI host.” error.

System information:
Nextcloud AIO
Debian (openmediavault image)
Static IP
Cloudflare
DOMAIN_NAME is cloud.domain.tld, domain.tld is a separate server with a separate website on it.
optional containers: collabora and thats it

Related logs:

nextcloud:

2024-09-01T15:59:05.974259876Z Collabora URL (used for Nextcloud to contact the Collabora server):
2024-09-01T15:59:05.974264225Z   https://DOMAIN_NAME
2024-09-01T15:59:05.974268235Z Collabora public URL (used in the browser to open Collabora):
2024-09-01T15:59:05.974330790Z   https://DONAIN_NAME
2024-09-01T15:59:05.974351629Z Callback URL (used by Collabora to connect back to Nextcloud):
2024-09-01T15:59:05.974357183Z   autodetected (will use the same URL as your user for browsing Nextcloud)

Collabora container(periodic error):

2024-09-01T15:36:49.754954336Z wsd-00007-00017 2024-09-01 18:36:49.754811 +0300 [ remotefontconfig_poll ] ERR  Remote config server has response status code: 0 (Unknown)| wsd/COOLWSD.cpp:1208

Collabora container(when trying to open document):

2024-09-01T15:37:38.899732503Z WOPI::CheckFileInfo failed for URI [https://DOMAIN_NAME/index.php/apps/richdocuments/wopi/files/630_ocoh941voayu?access_token=6hccyoDJEOtqSqWNOu1ymLgaBvyVyU2l&access_token_ttl=0]: 0 (Unknown) . Headers: 	Body: []| wsd/wopi/CheckFileInfo.cpp:95
2024-09-01T15:37:38.899777176Z wsd-00007-00019 2024-09-01 18:37:38.899590 +0300 [ websrv_poll ] ERR  #51: Invalid URI or access denied to [https://DOMAIN_NAME/index.php/apps/richdocuments/wopi/files/630_ocoh941voayu?access_token=6hccyoDJEOtqSqWNOu1ymLgaBvyVyU2l&access_token_ttl=0]| wsd/wopi/CheckFileInfo.cpp:109
2024-09-01T15:37:39.772383898Z wsd-00007-00019 2024-09-01 18:37:39.772168 +0300 [ websrv_poll ] ERR  #50: CheckFileInfo failed for [https%3A%2F%2FDOMAIN_NAME%3A443%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F630_ocoh941voayu], State::Fail| wsd/RequestVettingStation.cpp:272
2024-09-01T15:37:40.366501276Z WOPI::CheckFileInfo failed for URI [https://DOMAIN_NAME/index.php/apps/richdocuments/wopi/files/630_ocoh941voayu?access_token=6hccyoDJEOtqSqWNOu1ymLgaBvyVyU2l&access_token_ttl=0&permission=edit]: 0 (Unknown) . Headers: 	Body: []| wsd/wopi/CheckFileInfo.cpp:95
2024-09-01T15:37:40.366552016Z wsd-00007-00019 2024-09-01 18:37:40.366371 +0300 [ websrv_poll ] ERR  #52: Invalid URI or access denied to [https://DOMAIN_NAME/index.php/apps/richdocuments/wopi/files/630_ocoh941voayu?access_token=6hccyoDJEOtqSqWNOu1ymLgaBvyVyU2l&access_token_ttl=0&permission=edit]| wsd/wopi/CheckFileInfo.cpp:109

Related information:
Added 0.0.0.0/0 and ::0 into the “Allow list for WOPI requests” field to rule out cloudflare.
Disabled certificate check just in case.
Tried Talk, works perfectly fine.
No 127.0.1.1 in the hosts.
No related firewall rules.
Capabilities and Discovery link can be reached from both containers.
Probably not related but just in case:
I had to move data folder after initial setup because i forgot to change it during said setup.
The domain name in the "URL (and Port) of Collabora Online-serveri:
" field is just cloud.domainname.tld.

that is good but it’s only required from client and NC…

sounds like your CODE container can not access NC for some reason. first check could be curl https://cloud.domain.tld/status.php -v inside of CODE container… if this works I would follow the path of the outgoing request from CODE container to the internet, cloudflare, reverse proxy to Nextcloud container and check if the request arrives and if this is forwarded to the next station… your might have to increase verbosity to see successful requests… following this approach you will find the place where it fails and might see the reason why it fails…

look at Collabora integration guide for further details

*   Trying IP_ADRESS:443...
* Connected to cloud.domain.tld (IP_ADRESS) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.DOMAIN.TLD
*  start date: Jul 19 23:02:18 2024 GMT
*  expire date: Oct 17 23:02:17 2024 GMT
*  subjectAltName does not match cloud.domain.tld
* SSL: no alternative certificate subject name matches target host name 'cloud.domain.tld'
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'cloud.domain.tld'
More details here: https://curl.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.

Yep, seems to be an ssl issue.
cloud.domain.tld is the nextcloud server with its own static IP while domain.tld is another separate server with its own static IP and a separate unrelated website.
Im not super familiar with ssl and frankly hate that thing with passion, how do i go about fixing this?

Oh and i forgot to add that i did click “disable certificate verification” under “use your own server” in Office settings specifically to avoid dealing with ssl issues while im trying to fix things, shouldnt there be no ssl check?

“certificate validation” checkmark might apply for the Nextcloud application but definitely not for curl… but this is not really important - with an invalid cert you are in trouble - please issue valid certificate for the CODE server and test again. TLS is a requirement for WOPI protocol and each party, client, Nextcloud and CODE should be able to communicate over TLS to each other.

How do i go about doing this?

as an admin you should know how you request and install TLS certs… if not you better use one of the managed Nextcloud offers.

Could you give me some general directions? Im pretty confused as to what certificate is missing and where.

Nextcloud https on cloud.domain.tld is working, website’s https on domain.tld is working as well.
So what is going on exactly? its trying to check nextclouds certificate but failing? Its trying to check website’s certificate but failing?

You mentioned issuing certificate “for the CODE server”. Does CODE container need to have its own certificate for some reason?

every party must access CODE using valid https connection. There is no requirement to have separate TLS cert but it must be valid (public CA like letsencrypt is preferred as it is very hard to deploy self-issued certs correctly everywhere)

Shouldnt it use nextclouds certificate automatically then? Considering that the guide for how to turn office on is literally just: click collabora container in AIO interface and start your containers.
Im confused as to why does nextcloud works just fine but collabora throws a TLS error.

Also forgot to mention: do i absolutely need a separate subdomain for collabora? Like office.domain.tld?

In AiO CODE server uses the same URL as NC and could share same TLS cert… but in your case the TLS seems to be invalid:

Cloudflare add some challenges did you work through AiO note on Cloudflare?

1 Like

Man, im illiterate. So as i understand allowing all ip adresses in WOPI allow list wasnt enough, i should also try SKIP_DOMAIN_VALIDATION variable for master container?

Ok so i did try SKIP_DOMAIN_VALIDATION and i have also tried developer mode and disabling cloudflare for the domain.tld at the same time and yet it gives me the same error.

EDIT: it appears the curl command is now working, yet it still gives me a WOPI error.
EDIT2: ok here is the question: in the guide you’ve linked you write :

from the client, verify access to Collabora (use browser or run curl https://office.mydomain/hosting/discovery)

and you’ve also wrote that collabora uses the same link as NC, but then how do i test client access to collabora? what link should i use?
If its

https://mydomain.tld/apps/richdocumentscode/proxy.php?req=/hosting/capabilities
https://mydomain-tld/apps/richdocumentscode/proxy.php?req=/hosting/discovery

then it just gives me 404.

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