Keywords: Git Configuration | Self-Signed Certificates | SSL Security | Certificate Trust | Enterprise Git Deployment
Abstract: This article provides a comprehensive guide on securely configuring Git to accept specific self-signed server certificates, avoiding the security risks of completely disabling SSL verification. Through three core steps—obtaining certificates, storing certificates, and configuring Git trust—the article offers detailed operational guidelines using both OpenSSL and browser methods. It explains how to achieve precise certificate trust management via the http.sslCAInfo parameter and analyzes differences between LibGit2Sharp and external Git clients in certificate handling, supported by enterprise case studies, to deliver complete solutions for secure Git configuration in various scenarios.
Introduction
In enterprise Git deployment environments, using self-signed certificates is a common security practice, but completely disabling SSL certificate verification introduces significant security risks. This article presents a secure and practical solution by configuring Git to trust only specific self-signed certificates, implementing a security mechanism similar to SSH server key verification.
Obtaining Self-Signed Certificates
The first step in the configuration process is obtaining the server's self-signed certificate, which can be accomplished using command-line tools or graphical interfaces.
Using OpenSSL to Obtain Certificates
OpenSSL provides a standard method to directly connect to the server and extract the certificate. The following code demonstrates the complete certificate acquisition process:
openssl s_client -connect repos.sample.com:443 > temp_cert.txt
# Extract the certificate portion from the output
grep -A 100 "BEGIN CERTIFICATE" temp_cert.txt | grep -B 100 "END CERTIFICATE" > ~/git-certs/cert.pem
rm temp_cert.txt
After executing these commands, the certificate file cert.pem will contain the standard PEM-format certificate, with a structure as follows:
-----BEGIN CERTIFICATE-----
MIIDnzCCAocCBE/xnXAwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkRFMRUw
EwYDVQQIEwxMb3dlciBTYXhvbnkxEjAQBgNVBAcTCVdvbGZzYnVyZzEYMBYGA1UE
... (certificate content omitted) ...
/27/jIdVQIKvHok2P/u9tvTUQA==
-----END CERTIFICATE-----
Exporting Certificates Using a Browser
For users preferring graphical interfaces, modern browsers offer certificate export functionality. Using Firefox as an example:
- Visit the target Git server URL
- Click the lock icon in the address bar
- Select "Connection Security" → "More Information"
- Choose "View Certificate" in the security dialog
- Switch to the "Details" tab
- Click the "Export" button to save the certificate file
This method is particularly suitable when certificate exceptions have already been added via the browser, ensuring the obtained certificate matches exactly what the browser uses.
Certificate Storage and Management
An appropriate certificate storage strategy is crucial for maintaining secure access to multiple Git repositories.
Single Certificate Storage
For configurations involving a single server, using a dedicated certificate directory is recommended:
mkdir -p ~/git-certs
# Save the certificate file with a specific name
cp certificate.pem ~/git-certs/repos.sample.com.pem
Multiple Certificate Merging
When trusting multiple self-signed certificates is necessary, all certificates can be merged into a single file:
# Append multiple certificates to the same file
cat cert1.pem cert2.pem cert3.pem > ~/git-certs/all-certs.pem
The merged certificate file contains multiple certificate blocks, each independently enclosed between BEGIN CERTIFICATE and END CERTIFICATE markers.
Configuring Git to Trust Certificates
Git offers flexible configuration options for managing SSL certificate trust.
Global Configuration
For personal development environments, global configuration is the most convenient approach:
git config --global http.sslCAInfo ~/git-certs/cert.pem
This configuration affects all Git operations for the user, suitable for personal development workstations.
System-Level Configuration
In enterprise environments, system-level configuration can uniformly manage certificate trust for all users:
sudo git config --system http.sslCAInfo /etc/git-certs/enterprise-certs.pem
System-level configuration requires administrator privileges but ensures all Git clients on the system use the same certificate trust policy.
Verifying Configuration
After configuration, verification is essential to ensure correct setup:
# Check current configuration
git config --global --list | grep sslCAInfo
# Test Git operations
git ls-remote https://repos.sample.com/project.git
If configured correctly, Git operations should proceed normally without certificate verification errors.
Special Considerations in Enterprise Environments
Certificate management in enterprise environments may present additional challenges.
Limitations of LibGit2Sharp
As mentioned in the reference article, some integrated Git clients (e.g., LibGit2Sharp) may be unable to read the Windows Certificate Store:
// LibGit2Sharp might not handle enterprise CA certificates
var options = new CloneOptions
{
CredentialsProvider = (_url, _user, _cred) => new UsernamePasswordCredentials
{
Username = "username",
Password = "password"
}
};
Repository.Clone("https://gitlab.example.com/repo.git", "local-path", options);
In such cases, switching to an external Git client may be a more reliable solution.
External Git Client Configuration
When using an external Git client, the configuration process is identical to standard Git, but environment variables and paths must be correctly set:
# Set certificate path for Git for Windows
git config --global http.sslCAInfo C:/Users/username/git-certs/cert.pem
# Verify external client configuration
git --version
git config --list
Security Best Practices
When implementing certificate trust configuration, the following security principles should be adhered to:
Avoid Disabling SSL Verification
Never use git config --global http.sslVerify false, as this completely disables security verification for all HTTPS connections. If this option was previously set, it should be immediately unset:
git config --global --unset http.sslVerify
Certificate File Security
Certificate files should be protected with appropriate filesystem permissions:
# Set appropriate file permissions
chmod 600 ~/git-certs/cert.pem
# Consider encrypted storage in shared environments
Regular Certificate Updates
Self-signed certificates typically have expiration dates, so a certificate update process should be established:
# Check certificate expiration time
openssl x509 -in ~/git-certs/cert.pem -noout -dates
Troubleshooting
Common issues encountered during configuration and their solutions:
Certificate Format Validation
Ensure the certificate file format is correct:
# Verify PEM format
openssl x509 -in ~/git-certs/cert.pem -text -noout
Path and Permission Issues
Check certificate file paths and access permissions:
# Verify file existence and readability
ls -la ~/git-certs/cert.pem
# Test Git read capability
git config --global http.sslCAInfo ~/git-certs/cert.pem
git config --global --get http.sslCAInfo
Conclusion
By precisely configuring Git to trust specific self-signed certificates, convenient Git operations can be achieved without compromising security. This approach is safer than completely disabling SSL verification and more flexible and economical than using commercial CA certificates. Implementation in enterprise environments must consider integrated client limitations, resorting to external Git client solutions when necessary. Proper certificate management and regular maintenance are key to ensuring long-term secure operation.