[Bug]: Univention Join Phase Fails if signed certs installed prior to install of Nextcloud via App Center

[rotor-head]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Overview

Fresh install of a Univention Corporate Server backup domain controller, added signed certs via acme.sh/Letsencrypt, and installed NC via the App Center.

Subsequent running of the univention-run-join-scripts 50nextcloud.inst results in a cURL 60 error.

Without a successful join, users are unable to log in via SSO/SAML.

Notes regarding the issue

I've stepped through this process two different times.

• First, a successful condition for installation:

  • After completing a successful installation of the UCS server, immediately running the App Center installation of NC Hub completes the join phase successfully.

• Second, a failed condition for installation:

  • post successful installation, completing the addition of signed certs for the FQDN + SSO tldr causes the subsequent installation of NC to fail at the join phase.

Hacked work-around

In order to complete the join phase of the installation, the function nextcloud_curl() in 50nextcloud.inst was modified to change the curl flag from -s to -k result=$(curl -k "$@") The -k flag tells curl to ignore error raised from a self-signed certificate.

Steps to reproduce

1. Fresh install of a Univention Corporate Server backup domain controller, add signed certs via acme.sh/Letsencrypt, and install NC via the App Center.
2. In the Univention Portal, check the Domain Join page. Note the 50nextcloud step shows 'pending' status.
3. Further review /var/log/univention/join.log for details of the failure. In my case:
   curl failed with error 60, parameters were\n\t-X POST -H OCS-APIREQUEST: true -u nc_admin:snip>sniphttps://FQDN/nextcloud/ocs/v2.php/apps/user_ldap/api/v1/config
   Failed to request an LDAP config id from Nextcloud
   EXITCODE=1

Expected behavior

The expected behavior would account for updates from self-signed certificates to signed certificates within the installation phase of the NC container in order to permit a successful join phase.

Nextcloud Server version

28

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
"system": {
"passwordsalt": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"trusted_domains": [
"ucs-ad.domain.com",
"reveille.domain.com"
],
"datadirectory": "REMOVED SENSITIVE VALUE",
"dbtype": "pgsql",
"version": "28.0.7.4",
"overwrite.cli.url": "https://reveille.domain.com/nextcloud",
"dbname": "REMOVED SENSITIVE VALUE",
"dbhost": "REMOVED SENSITIVE VALUE",
"dbport": "",
"dbtableprefix": "oc_",
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"installed": true,
"instanceid": "REMOVED SENSITIVE VALUE",
"updatechecker": false,
"upgrade.disable-web": true,
"memcache.local": "\OC\Memcache\APCu",
"overwriteprotocol": "https",
"overwritewbroot": "/nextcloud",
"htaccess.RewriteBase": "/nextcloud",
"ldapProviderFactory": "OCA\User_LDAP\LDAPProviderFactory",
"trusted_proxies": "REMOVED SENSITIVE VALUE",
"one-click-instance": true,
"one-click-instance.user-limit": 500,
"one-click-instance.link": "https://nextcloud.com/univention/"
}
}

List of activated Apps

Enabled:

• activity: 2.20.0
• circles: 28.0.0
• cloud_federation_api: 1.11.0
• comments: 1.18.0
• contactsinteraction: 1.9.0
• dashboard: 7.8.0
• dav: 1.29.2
• federatedfilesharing: 1.18.0
• federation: 1.18.0
• files: 2.0.0
• files_pdfviewer: 2.9.0
• files_reminders: 1.1.0
• files_sharing: 1.20.0
• files_trashbin: 1.18.0
• files_versions: 1.21.0
• firstrunwizard: 2.17.0
• logreader: 2.13.0
• lookup_server_connector: 1.16.0
• nextcloud_announcements: 1.17.0
• notifications: 2.16.0
• oauth2: 1.16.3
• password_policy: 1.18.0
• photos: 2.4.0
• privacy: 1.12.0
• provisioning_api: 1.18.0
• recommendations: 2.0.0
• related_resources: 1.3.0
• serverinfo: 1.18.0
• settings: 1.10.1
• sharebymail: 1.18.0
• spreed: 18.0.12
• support: 1.11.1
• survey_client: 1.16.0
• systemtags: 1.18.0
• text: 3.9.2
• theming: 2.3.0
• twofactor_backupcodes: 1.17.0
• user_ldap: 1.19.0
• user_status: 1.8.1
• viewer: 2.2.0
• weather_status: 1.8.0
• workflowengine: 2.10.0
  Disabled:
• admin_audit: 1.18.0
• bruteforcesettings: 2.8.0
• encryption: 2.16.0
• files_external: 1.20.0
• onlyoffice: 9.2.2 (installed 9.4.0)
• richdocuments: 8.3.8 (installed 8.3.12)
• suspicious_login: 6.0.0
• twofactor_totp: 10.0.0-beta.2

Nextcloud Signing status

no errors have been found

Nextcloud Logs

Cleared the log file post join. No data available.

Additional info

No response

[blizzz]

You said it worked once, but not the other time. Both with the same repro steps?

[rotor-head]

Correct. The differentiating factor was using signed certificates on a new server install.

• Installing from the App Center prior to setting up signed certificates (Let's Encrypt) yielded a successful installation.

• Installing post signed certificates caused a failure in the cURL step during the join phase.

You said it worked once, but not the other time. Both with the same repro steps?

[blizzz]

My gut feeling is that there was something wrong when issueing the new certificates. Maybe they were not populated everywhere, or the LDAP service has not been reloaded?

[rotor-head]

Possibly. I don't know which cert is being pulled by curl during the check phase or how a self-signed cert is successfully verified but signed certs give an error. The error occurs after a full system restart as well, so presumably LDAP services would be reloaded.

Which cert is being checked?

[blizzz]

The joinscript runs on the host, so system defaults. After installing certificates update-ca-certificates has to be run on the system.

curl failed with error 60, parameters were -X POST -H OCS-APIREQUEST: true -u nc_admin:snip https://FQDN/nextcloud/ocs/v2.php/apps/user_ldap/api/v1/config

The TLS termination happens on the UCS host, it is rather that apache needs a reload there.