Univention Bugzilla – Bug 44845
cannot use nextcloud if hostname does not match external DNS name
Last modified: 2020-07-03 20:56:09 CEST
I setup a DC master on a root server with a public IP. The hostname known in public DNS is nc.external.name. I can connect to the DC masters UMC through https://nc.external.name. The name that the DC master got during system setup is nc.mydom.local. Then I installed the nextcloud app. It was installed in a docker container. ------------------ Sidenote (not this bug): -------------------- I had installed it on the command line, and it said that the join script did run: Installing join script /var/cache/univention-appcenter/appcenter.software-univention.de/4.1/nextcloud_20170512120050.inst univention-run-join-scripts: runs all join scripts existing on local computer. [..] Running 50nextcloud.inst done [..] But when I logged into the UMC, it was pending. I ran it again. The join.log clearly shows, that it did run the first time already. -------------------------------------------------------------- Anyway - this bug is about this: When I go to the portal, I cannot log into nextcloud, because the link goes to the internal DNS nc.mydom.local which is unknown on the internet. Thus I went to the LDAP browser and added an entry to the portal_entry object, that points to the external hostname that I use to connect to the masters UMC. Now I have a second portal link to nextcloud (one with internal DNS, one with external DNS). If I click the new link I get to the nextcloud page. And here is the problem. The page displays: -------------------------------------------------------------- You are accessing the server from an untrusted domain. Please contact your administrator. If you are an administrator of this instance, configure the "trusted_domains" setting in config/config.php. An example configuration is provided in config/config.sample.php. Depending on your configuration, as an administrator you might also be able to use the button below to trust this domain. -------------------------------------------------------------- There is a button "Add "nc.external.name" as trusted domain", but it is a link with the internal DNS (https://master.mydom.local/nextcloud/index.php/settings/admin?trustDomain=nc.<external name>) If I copy&paste the link and replace https://master.mydom.local/... with https://nc.external.name/ I end up on the same page. If I log into the UCS, I cannot edit the config/config.php*, because it is in the docker container. → nextcloud app cannot be used on a server where internal name != external name.
After fixing this problem by adding master.mydom.local to my /etc/hosts, I don't get the "untrusted domain" problem anymore. But login is still not possible. The reason is (also why the join script never finished), that in the containers /etc/resolv.conf Googles two nameservers (8.8.8.8, 8.8.4.4) are configured. Those cannot resolve master.mydom.local, and thus nextcould cannot access the LDAP on the host. After adding the master to /etc/hosts and a nameserver to /etc/resolv.conf, login to nextcloud works. → fix /etc/resolv.conf
Which /etc/resolv.conf do you mean? The one in the Nextcloud container?
still happens with 4.1/nextcloud=18.0.1-0 Both the host and the container can resolve DC Master. What about the curl certificate issue, Nico mentioned on https://help.univention.com/t/nextcloud-join-script/10895/2
# curl https://example.com curl: (51) SSL: no alternative certificate subject name matches target host name 'example.com'
# curl https://example.local curl: (51) SSL: no alternative certificate subject name matches target host name 'example.local'
(In reply to Sebastian from comment #5) > # curl https://example.local > curl: (51) SSL: no alternative certificate subject name matches target host > name 'example.local' Where have those certificates been obtained? How have they been added to the UCS system?
My mistake! Servername of the host running nextcloud container is something like: somehost.univention.intranet When the the join script trying to reach DC Master, than IMHO it is the certificate, created by the DC Master.
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.