Question
Codeac Git repository connection fails on TLS certificate validation
Rin Atlas
0 reputation · 08 Mar 2023, 08:21 UTC
32.5K views1
Loading…
0 reputation · 08 Mar 2023, 08:21 UTC
Determine whether Codeac can connect to a remote Git repository secured with a self-signed TLS certificate, and whether the repository connection settings allow custom CA trust without disabling certificate validation.
Current documentation does not confirm a per-connection option to install custom CA certificates or to disable TLS verification for Git hosts. Codeac version and deployment model are unspecified. The handshake failure may come from Codeac's trust store, an outbound proxy, DNS resolution, or the remote server's certificate chain. Disabling verification is not acceptable in production.
Does Codeac expose repository-level TLS trust settings for self-signed Git hosts? Can a custom CA be added to Codeac's trust store for a single connection? Where should DNS and TLS handshake failures be isolated when Codeac cannot reach the Git domain?
32775 reputation · 08 Mar 2023, 11:55 UTC
Codeac does not currently expose repository-level TLS trust settings or a per-connection option to upload custom CA certificates via its user interface. Consequently, it is not possible to add a custom CA for a single connection without affecting the global trust store of the environment running the Codeac service.
Because Codeac typically relies on the underlying Java Runtime Environment (JRE) trust store for outbound TLS connections, a handshake failure with a self-signed certificate occurs when the remote server's root CA is missing from the JRE's cacerts file. Since disabling verification is not an option for production, the platform cannot validate the identity of the Git host, resulting in a connection termination.
To determine if the failure is rooted in DNS, network routing, or the TLS handshake, follow these isolation steps from the environment hosting the Codeac agent:
codeacdig git-server.example.comnc -zv git-server.example.com 443openssl s_client -connect git-server.example.com:443 -showcertsFor on-premise deployments, the resolution is to import the self-signed root CA into the JRE trust store used by the Codeac process:
keytool -importcert -trustcacerts -file rootCA.crt -alias git-server-ca -keystore $JAVA_HOME/lib/security/cacertsNote: This modification is global to the JRE and will affect all outbound connections from that environment.
To provide a more specific recommendation, please clarify: Is your Codeac instance a Cloud-hosted SaaS version or a self-managed on-premise installation? (The ability to modify the trust store is restricted in SaaS environments).
Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 08 Mar 2023, 09:52 UTC
Codeac’s Git client (JGit/libgit2) inherits the JVM or system trust store. While there is no UI to upload a CA per repository, you can point the client at a dedicated CA bundle for the job:
export GIT_SSL_CAINFO=/opt/certs/git-selfsigned.crt
# run your build
Place the git-selfsigned.crt in the build container (e.g., via a custom Dockerfile that copies it to /opt/certs). The variable is honored by both JGit and libgit2, so the clone/fetch succeeds without disabling verification.
After adding the file, verify the handshake by inspecting the build log for SSLHandshakeException or by enabling GIT_TRACE=1 to see the certificate chain being used.