Certificate error after upgrade to 5.0.0 from 4.0.6

Infinite Scale
,
1

Certificate error after upgrade to 5.0.0 from 4.0.6

I am looking for troubleshooting guidance. What can I try next?

Setup

browser (https://owncloud.example.com) ↔ [Internet] ↔ (WAN) HAproxy reverse proxy on pfSense in a VM ↔ (LAN) OCIS in docker on a Ubuntu 22.04 VM

This setup has worked from OCIS 2.0.0 through following upgrades (docker compose pull):

  • 2.0.0 to 3.0.0
  • 3.0.0 to 4.0.2
  • 4.0.2 to 4.0.3
  • 4.0.3 to 4.0.4
  • 4.0.4 to 4.0.5
  • 4.0.5 to 4.0.6

After upgrade from 4.0.6 to 5.0.0:

On the client browser (macOS 14.4.1 safari 17.4.1), when login I receive the following error mesages:

Unexpected HTTP response: 500. Please check your connection and try again.

I expect to pass login page and see the OCIS personal dashboard.

Error messages on the docker side (filtered by ERR):

2024-04-13T07:14:47Z ERR handleConnection ber.ReadPacket | service=idm error=remote error: tls: bad certificate line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50
2024-04-13T07:14:47Z ERR identifier failed to logon with backend | service=idp error=ldap identifier backend logon connect error: LDAP Result Code 200 "Network Error": tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2024-04-13T07:14:47Z is after 2024-04-05T08:43:54Z line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50

I’ve checked the certificate for owncloud.example.com is valid on pfSense.
I am using the built-in IDP.

$ docker version
Client: Docker Engine - Community
 Version:           26.0.1
 API version:       1.45
 Go version:        go1.21.9
 Git commit:        d260a54
 Built:             Thu Apr 11 10:53:21 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.0.1
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.9
  Git commit:       60b9add
  Built:            Thu Apr 11 10:53:21 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.31
  GitCommit:        e377cd56a71523140ca6ae87e30244719194a521
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

At 4.0.6, docker-compose.yml (no .env file):

version: "3.9"

services:

  owncloud:
    hostname: owncloud
    image: owncloud/ocis:4.0.6
    entrypoint:
      - /bin/sh
    # Run ocis init to initialize a configuration file with random secrets.
    # It will fail on subsequent runs, because the config file already exists.
    # Therefore we ignore the error and then start the ocis server
    command: ["-c", "ocis init || true; ocis server"]
    ports:
      - 9200:9200
    networks:
      ocis-net:
    environment:
      OCIS_URL: https://owncloud.example.com
      OCIS_LOG_LEVEL: "info"
      OCIS_LOG_COLOR: "false"
      PROXY_TLS: "false" # do not use SSL between Traefik and oCIS
      # INSECURE: needed if oCIS / Traefik is using self generated certificates
      OCIS_INSECURE: "true"
      # admin user password
      IDM_ADMIN_PASSWORD: "snipped" # this overrides the admin password from the configuration file
      # demo users
      IDM_CREATE_DEMO_USERS: "false"
    volumes:
      - /mnt/owncloud_config:/etc/ocis
      - /mnt/owncloud_data:/var/lib/ocis
    logging:
      driver: "local"
    restart: always

networks:
  ocis-net:

At 5.0.0, docker-compose.yml (no .env file):

version: "3.9"

services:

  owncloud:
    hostname: owncloud
    image: owncloud/ocis:5.0.0
    entrypoint:
      - /bin/sh
    # Run ocis init to initialize a configuration file with random secrets.
    # It will fail on subsequent runs, because the config file already exists.
    # Therefore we ignore the error and then start the ocis server
    command: ["-c", "ocis init || true; ocis server"]
    ports:
      - 9200:9200
    networks:
      ocis-net:
    environment:
      OCIS_URL: https://owncloud.example.com
      OCIS_LOG_LEVEL: "info"
      OCIS_LOG_COLOR: "false"
      PROXY_TLS: "false" # do not use SSL between Traefik and oCIS
      # INSECURE: needed if oCIS / Traefik is using self generated certificates
      OCIS_INSECURE: "true"
      # admin user password
      IDM_ADMIN_PASSWORD: "snipped" # this overrides the admin password from the configuration file
      # demo users
      IDM_CREATE_DEMO_USERS: "false"
      OCIS_SERVICE_ACCOUNT_ID: "snipped"
      OCIS_SERVICE_ACCOUNT_SECRET: "snipped"
    volumes:
      - /mnt/owncloud_config:/etc/ocis
      - /mnt/owncloud_data:/var/lib/ocis
    logging:
      driver: "local"
    restart: always

networks:
  ocis-net:

I thought maybe 5.0.1 could fix something, so I just docker compose pull as usual and also added

    environment:
      PROXY_HTTP_ADDR: "0.0.0.0:9200"

Same errors with or without the above change.

For each upgrade, I did read the upgrade section in the official docs for notable and breaking changes.
I could have missed something, but I don’t think so.

Unfortunately, I don’t have backups for volumes used in the docker-compose.
Is it safe to just run 4.0.6’s docker-compose.yml now, as a downgrade workaround?

2

Hey,

i’m not sure but to me it sounds indeed there is an expired certificate somewhere in the setup which sounds to be unrelated to the update from 4.0 to 5.0.

3

Thanks for the reply.

Indeed as you said, I found /var/lib/ocis/idm/ldap.crt has expired. The date on the certificate matches the date in the error message.

I’m using the built-in LDAP / IDM.
In the 4.0 and 5.0 docs, it says

By default, IDM generates a self-signed certificate and key on first startup to be able to provide TLS-protected services.

Does OCIS not auto-regenerate when the certificate expires?
What is the recommended way to renew this cert?

Thanks!

4

Hey,

no software that i have used so far (and this is a long list) has ever auto-regenerate software (expect via 3rdparty scripts like let’s encrypt) so i don’t think that oCIS would be special in this case.

Maybe the ownCloud people are providing some info on this in their documentation?

5

Thank you for the quick reply.

I also suspect the same.
The docs have not discuss renewal.

There is OCIS_LDAP_INSECURE environment variable.

Disable TLS certificate validation for the LDAP connections. Do not set this in production environments.

Set to true solves the problem. I am able to reach the personal dashboard like before.

Need to figure out how to renew certs…

1 Like
6

According to an issue on OCIS github, after deleting ldap.crt and ldap.key, OCIS will generate new ones on startup. I’ve confirmed this works for me.

Ref: Certificate `ldap.crt` expired no login possible · Issue #7805 · owncloud/ocis · GitHub

2 Likes
7

Hey,

i think the ownCloud people would be happy about an issue raised below so that they maybe could consider to include this information in the documentation:

8

Hi @tom42, Thanks for following up and sharing suggestion.

I’m quite happy with the current state of things.
I would also be just as happy if others build on top of the info I shared.

Nevertheless, @tom42 thank you for the help on the forum, I see that you are helping and caring about it.

Edit: @tom42, from your other posts in other threads. I get a feeling that you are trying to nudge people to interact on github issues, which I see is probably more lively and healthier. I also agree and IMHO recommend so.

1 Like
9

Hey,

it is great that you have found a solution for this. I think it would really help if a new GitHub issue is getting created (i don’t have a GitHub account so i’m not able to do so) so that others are able to find this solution more easily in the past.

About using GitHub:

From what i know developers tend to work solely on GitHub issues (not only in ownCloud but on every software project i had used so far), so i think everything which requires a developer (or some one else from the ownCloud people writing e.g. documentation) to look at should be posted on GitHub because i think it is not guranteed that they will notice it in a community forums in between all the setup / configuration questions.