Weblate HTTPS component creation fails with certificate validation errors for internally signed VCS hosts

Weblate's outbound HTTPS repository access relies on the host operating system's TLS stack and certificate trust store rather than a Weblate-specific CA configuration. When adding or updating a component from an external version-control host that presents an internally signed certificate, administrators may encounter TLS validation errors in the Weblate interface and worker logs. Because Weblate does not expose a per-component option to disable certificate verification or attach a custom CA for a single repository, the underlying trust configuration must be adjusted at the host or container level.

DNS resolution for these repository hosts is performed by the Weblate process context, which means internal or split-horizon hostnames must be resolvable from the same environment that runs Weblate. The certificate presented to end users browsing Weblate is managed separately by the reverse proxy or WSGI server and does not affect outbound repository connections. Different deployment methods—official container images, source installations, and OS packages—may expose different CA bundle locations and environment-variable behavior, adding uncertainty to where the internal CA should be trusted.

What diagnostic approach best isolates whether the failure originates from DNS resolution or TLS certificate validation for a specific VCS host? How can administrators confirm that the active CA bundle used by the Weblate process includes the internal certificate authority? Which environment variables or configuration files control the TLS trust path for outbound repository connections across container and source-based deployments?