Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Self signed certificate rejected even when explicitly disabled SSL verification #10917

Open
michnovka opened this issue Jan 13, 2025 · 3 comments
Labels
bug Something isn't working unconfirmed

Comments

@michnovka
Copy link

michnovka commented Jan 13, 2025

I updated collabora/code docker image to 24.04.11.2 and now I have issue that I cannot access office from nextcloud. The problem is not Nextcloud -> Collabora, but the other way around, Collabora -> Nexcloud (as can be seen from the bellow screenshot):

Both collabora and nextcloud use self signed certs on my setup.

Here nextcloud can reach collabora no issues:
image

As you can see self signed SSL is allowed. But when I open a document:

image

I am using this docker-compose file with explicitly disabled SSL verification:

services:
  collabora:
    image: collabora/code
    tty: true
    restart: unless-stopped
    cap_add:
      - MKNOD
    ports:
      - "127.0.0.1:9980:9980"
    environment:
      - aliasgroup1=https://cloud.XXXXXX:443
      - username=admin
      - password=XXXXXXXXXXXXX
      - dictionaries=en_US
      - extra_params=--o:ssl.ssl_verification=false
    extra_hosts:
      - "cloud.XXXXXX:100.111.0.5"
    volumes:
      - /etc/localtime:/etc/localtime:ro

Here is relevant docker log:

collabora-1  | wsd-00001-00033 2025-01-13 11:19:57.652211 +0100 [ websrv_poll ] ERR  #34: WOPI::CheckFileInfo failed for URI [https://cloud.XXXXXX/index.php/apps/richdocuments/wopi/files/90916_ochoj4cc0e60?access_token=XXXXXXXXXXXx&access_token_ttl=0]: 403 (Forbidden) Forbidden. Headers: Server: nginx / Date: Mon, 13 Jan 2025 10:19:57 GMT / Content-Type: application/json; charset=utf-8 / Content-Length: 2 / Connection: keep-alive / Set-Cookie: ochoj4cc0e60=4s1q1miloehgbspv67mc64vv4i; path=/; secure; HttpOnly; SameSite=Lax / X-Request-Id: XXXXXXXXXXXXXX / Cache-Control: no-cache, no-store, must-revalidate / Content-Security-Policy: default-src 'none';base-uri 'none';manifest-src 'self';frame-ancestors 'none' / Feature-Policy: autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none' / X-Robots-Tag: noindex, nofollow / Referrer-Policy: no-referrer / X-Content-Type-Options: nosniff / X-Frame-Options: SAMEORIGIN / X-Permitted-Cross-Domain-Policies: none / X-XSS-Protection: 1; mode=block      Body: [[]]| wsd/wopi/CheckFileInfo.cpp:98
collabora-1  | wsd-00001-00033 2025-01-13 11:19:57.652232 +0100 [ websrv_poll ] ERR  #34: Access denied to [https://cloud.XXXXXX/index.php/apps/richdocuments/wopi/files/90916_ochoj4cc0e60?access_token=XXXXXXXXXXXXXXXXXXX&access_token_ttl=0]| wsd/wopi/CheckFileInfo.cpp:112
collabora-1  | wsd-00001-00033 2025-01-13 11:19:58.217826 +0100 [ websrv_poll ] ERR  #32: CheckFileInfo failed for [https%3A%2F%2Fcloud.XXXXX%3A443%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F90916_ochoj4cc0e60], State::Fail| wsd/RequestVettingStation.cpp:272

This set-up worked fine few months back.

EDIT: I have confirmed that 24.04.3.1.1 works fine

@jazevedo-coll
Copy link

Hello @michnovka from what version did you update from?

Also, if you add --o:ssl.termination=true to your extra params:

- extra_params=--o:ssl.ssl_verification=false --o:ssl.termination=true

Does the issue persist?

@michnovka
Copy link
Author

michnovka commented Jan 13, 2025

Hi @jazevedo-coll , thanks for the idea, I can confirm the latest 24.04.11 version works well with

- extra_params=--o:ssl.ssl_verification=false --o:ssl.termination=true

What does that switch do? And is this still a bug or expected? Thanks!

P.S. I do not know from where I migrated, but when debugging I was going back version by version until 2024.04.8 where the issue was still present. Then I just tried larger step to 2024.04.3 and this works without the new extra param.

P.P.S. before it used to work even without the ssl.ssl_verification=false - I added that only now as part of debugging as I found it in some other issues on github.

@timar
Copy link
Member

timar commented Jan 14, 2025

How odd! (look like the same bug as #10911)
ssl.ssl_verification is false in collabora/code by default.
ssl.termination=true should be used together with ssl.enable=false, but you did not set ssl.enable.
This is only theory, how things should work (according to the manual).
I can only think of a recent regression, maybe latest CODE does not interpret these settings the way it should.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working unconfirmed
Projects
Status: No status
Development

No branches or pull requests

3 participants