This message was deleted.

your issue seems to be with the ingress controller, not rancher. I assume you're using ingress-nginx? Are there any hints in the ingress controller logs? Did the ingress resource get created correctly? Check the

spec.tls[0]

part if it has the right

host

and

secretName

section. and if the secret was created in the right namespace.

@microscopic-diamond-94749 thanks a lot for your hint; it was right to the point! Your assumption regarding the type of the ingress controller was correct. I found the following error in the ingress controller's log:

"Ignoring ingress because of error while validating ingress class" ingress="cattle-system/rancher" error="ingress does not contain a valid IngressClass"

So, I fortunately immediately realized my error. I had set the Rancher server service type to LoadBalancer, and mapped the FQDN to the load balancer IP. After setting the ingress class to nginx, and the service type back to ClusterIP, mapping the FQDN to the ingress controller's IP address, and restarting Rancher server, the certificate chain got finally fixed. However, now the cluster agent gets stuck to the following point as shown in its log:

INFO: Using resolv.conf: search cattle-system.svc.mas.local svc.mas.local mas.local nameserver 169.254.25.10 options ndots:5

and finally gets terminated not being able to download the CA root certificate from the /v3/settings/cacerts endpoint. In my opinion, it is a network connectivity-related issue as the connections between the central station on which Rancher server is running and the peripheral stations whose clusters we want to import is too slow. Therefore, we may have to abandon the idea of having a central Rancher server for centralized monitoring, and instead deploy a separate Rancher server to each peripheral cluster.

what was the issue?

I have not yet found out. It may have needed time as the connection is slow.