Question
Weblate HTTPS component creation fails with certificate validation errors for internally signed VCS hosts
Sky Finch
0 reputation · 13 Feb 2021, 03:45 UTC
118.7K views
Loading…
0 reputation · 13 Feb 2021, 03:45 UTC
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?
34775 reputation · 13 Feb 2021, 04:32 UTC
To determine if a connection failure is caused by DNS resolution or TLS validation, you must execute diagnostics from the exact environment where the Weblate process (web or worker) is running. A failure in the Weblate UI is often generic; the distinction is found in the network layer.
Run a basic lookup to ensure the VCS hostname resolves to the expected internal IP address:
weblate# From inside the Weblate container or host
ping -c 3 vcs.internal.example.com
# OR
dig vcs.internal.example.comIf these commands fail or return an incorrect IP, the issue is DNS-related (e.g., missing entries in /etc/hosts or incorrect DNS server configuration in the container runtime).
If DNS resolves, test the TLS handshake specifically. Use openssl to inspect the certificate chain presented by the VCS host:
openssl s_client -connect vcs.internal.example.com:443 -showcertsLook for Verification error: unable to get local issuer certificate. This confirms that while the server is reachable, the Weblate environment does not trust the internal Certificate Authority (CA) that signed the VCS certificate.
Weblate relies on the Python requests library and the underlying OS TLS stack. It does not have a per-component CA setting.
The active CA bundle is typically controlled by the following environment variables. If these are unset, the system defaults to the OS standard paths (e.g., /etc/ssl/certs on Debian/Ubuntu or /etc/pki/tls/certs on RHEL/CentOS):
SSL_CERT_FILE: Path to a single PEM-formatted CA bundle file.SSL_CERT_DIR: Path to a directory containing multiple CA certificates.To resolve the validation error, the internal CA root certificate must be added to the system trust store:
rootCA.crt into the container (e.g., /usr/local/share/ca-certificates/).
# For Debian/Ubuntu based images
update-ca-certificatesRequired Diagnostic Detail: To provide a specific file path for the CA update, please specify if you are using the official Docker images (Alpine or Debian based) or a source-based installation on a specific Linux distribution.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.