Univention Bugzilla – Bug 50526
Self signed UCS certificate is not valid for "plain domain"
Last modified: 2024-01-26 15:02:46 CET
Apparently, UCS' DNS is configured to accept not only https://master.intranet.mydomain.de but also https://intranet.mydomain.de which is answered by "master". But the certificate that we present does not include this name, thus the browser does not continue (until the user explicitly accepts the "wrong" certificate). This may be an even bigger problem for software that is not a browser, e.g., a file sharing client. We should add the domainname to the list of alternative names in the certificate. I do not know which setting is responsible for all that and why "master" answers and how one could change that. In this case (the change), the other certificate would need to have the new alternative name as well. Also, this may be a (separate) issue in Lets encrypt?
> Apparently, UCS' DNS is configured to accept not only https://master.intranet.mydomain.de but also https://intranet.mydomain.de which is answered by "master". FYI: I guess that's because we had to register A-records with the dns/forward_zone object for Samba/AD domains (MS introduced that so Windows Clients can access the sysvol share via //domain.name/sysvol). What you get is a round robin of the IP addresses of all UCS Samba/AD DCs. To prove my theory I removed the arecord entries from the dns/forward_zone object, cleared the nscd cache (nscd -i hosts) and then "host domain.name" doesn't return anything. The I quickly stopped samba, to avoid the samba_dnsupdate service to re-add the addresses (it does this periodically every 5 minutes or so, to ensure connectivity). And then I get this: root@master10:~# LANG=C wget http://ar41i1.qa --2019-11-14 02:26:39-- http://ar41i1.qa/ Resolving ar41i1.qa (ar41i1.qa)... failed: Name or service not known. wget: unable to resolve host address 'ar41i1.qa' Where before I had (with two UCS Samba/AD DCs): root@master10:~# LANG=C wget http://ar41i1.qa --2019-11-14 02:25:10-- http://ar41i1.qa/ Resolving ar41i1.qa (ar41i1.qa)... 10.200.8.10, 10.200.8.11 Connecting to ar41i1.qa (ar41i1.qa)|10.200.8.10|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://ar41i1.qa/univention/ [following] --2019-11-14 02:25:10-- http://ar41i1.qa/univention/ Reusing existing connection to ar41i1.qa:80. HTTP request sent, awaiting response... 302 Found Location: http://ar41i1.qa/univention/portal/ [following] --2019-11-14 02:25:10-- http://ar41i1.qa/univention/portal/ Reusing existing connection to ar41i1.qa:80. HTTP request sent, awaiting response... 200 OK
This is not a "DNS" bug, but a bug in "Samba4" or "SSL": If they add a new "DNS-name → Host-IP-address"-mapping and expect that new mapping to be valid when using TLS, they must trigger the re-creation of the host certificate with additional SANs. Please notice that UCS does not have a mechanism to roll-out new/updated certificates by its own, so currently that must be done by a human administrator. (bug #50809, bug #54505, bug #30294)