Repository Access Fails Behind a Domain Allowlist After TuxCare Mirror Redirects

Issue

Servers that allow outbound HTTPS only to specific hostnames can no longer reach TuxCare repositories, because repo.tuxcare.com now redirects to mirror domains that are not on the allowlist. For example:

repo.tuxcare.com -> repo.els.tuxcare.bunny.cl-mirror.net

Environment

• TuxCare
• KernelCare
• ELS

Solution

Allow these domain patterns for outbound HTTPS (TCP port 443) in your firewall or proxy policy:

*.tuxcare.com
*.cl-mirror.net
*.tc-mirror.net
*.cloudlinux.com
*.kernelcare.com

# curl -sIL https://repo.tuxcare.com/ | grep -i '^location'

Configure these as domain rules on your firewall or proxy, using SNI or URL based matching. Do not use IP address objects resolved from these names. The mirror and CDN hosts behind them change, so a resolved IP list will go stale.

Cause

TuxCare repositories are now served through a new mirror system. Requests to repo.tuxcare.com are redirected to mirror and CDN hosts under several of our domains, such as cdn-repo.tuxcare.com, repo.tuxcare.bunny.cl-mirror.net and repo.els.tuxcare.bunny.cl-mirror.net. All of these domains belong to TuxCare and CloudLinux. The hostnames in the redirect chain can change as the mirror network evolves.

An allowlist that contains only individual hostnames, such as the ones listed in the product prerequisites (cln.cloudlinux.com, repo.tuxcare.com, rollout.tuxcare.com), lets the first request through but blocks the redirect target, so yum fails to download repository metadata. Allowing the parent domains with wildcards covers both the current mirror hosts and future ones, so the allowlist does not need to change each time a new mirror hostname appears.