Resolving Certificate Verification Failure in WSL Ubuntu for add-apt-repository

The add-apt-repository command fails with certificate verification errors in WSL Ubuntu when network security policies intercept TLS traffic. This occurs because the interception proxy uses a custom root certificate not present in the system’s trusted store. You can resolve this by downloading the proxy’s CA certificate and installing it into /usr/local/share/ca-certificates/, then running update-ca-certificates.

Understanding the Root Cause

When you use tools like add-apt-repository or apt update inside Windows Subsystem for Linux (WSL), the environment relies on the standard Ubuntu trust store to verify SSL/TLS certificates. In many corporate or educational networks, a transparent proxy or firewall intercepts HTTPS traffic to scan for malware or enforce policy. This process requires the proxy to present its own digital certificate instead of the original site’s certificate. Because your WSL instance does not recognize this custom Certificate Authority (CA) as a trusted source, OpenSSL rejects the connection with a "certificate verification failed" error. This is distinct from general network connectivity issues; if you can browse the web in Windows but cannot install packages in WSL, the issue is almost certainly related to certificate trust rather than network access. The WSL kernel shares the network interface with the host Windows machine, so the traffic flows through the same proxy, but the Linux guest does not automatically inherit the host’s trusted certificates unless explicitly configured.

Distinguishing from Other Network Issues

It is important to differentiate this problem from other common WSL networking quirks. For instance, some users encounter difficulties importing distros or managing disk space due to configuration errors unrelated to TLS. If you are experiencing installation failures or storage anomalies, those may require different troubleshooting steps. However, specific errors mentioning "SSL: CERTIFICATE_VERIFY_FAILED" or "unable to get local issuer certificate" point directly to the trust store mismatch described here.

Identifying the Interception Proxy

Before adding any certificates, you must identify which organization or device is performing the interception. Most commonly, this is a corporate security appliance provided by your IT department. You will need the public CA certificate used by this proxy. This file is typically available in one of two ways: 1. Direct Download: Some proxies provide a direct link to download the root certificate, often accessible via a specific URL within the organization’s intranet or portal. 2. Export from Browser: If you have administrative access to the Windows host where the proxy is installed, you can export the certificate from your web browser (Chrome, Edge, or Firefox). Navigate to the settings under Privacy and Security > Manage Certificates, locate the certificate issued by your organization, and export it in Base64 encoded X.509 format (.cer or .crt). Ensure that you obtain the correct root or intermediate CA certificate. Do not attempt to capture certificates dynamically using packet sniffers unless you have explicit permission, as this can be complex and prone to error. The static root certificate is the most reliable solution for persistent package management operations.

Installing the Certificate in WSL Ubuntu

Once you have the certificate file, follow these steps to integrate it into the WSL Ubuntu environment. Open your WSL terminal and ensure you have sudo privileges. First, create a directory for local custom certificates if it does not already exist. While /usr/local/share/ca-certificates/ is the standard location, ensuring the directory exists prevents permission errors during the next step.

sudo mkdir -p /usr/local/share/ca-certificates/extra

Next, copy your downloaded certificate file into this directory. Rename the file to end with .crt if it has a different extension. For example, if your file is named company-root.cer, move it as follows:

sudo cp ~/Downloads/company-root.cer /usr/local/share/ca-certificates/extra/company-root.crt

You can place multiple certificates in this folder if your network uses multiple CAs. Ensure the files are readable by the system. After copying the file, you must trigger the certificate update process. Run the following command to rebuild the trust store:

sudo update-ca-certificates

This command scans the /usr/local/share/ca-certificates/ directory and updates the /etc/ssl/certs/ca-certificates.crt file, which is used by OpenSSL and APT. You should see output indicating that new certificates were added.

Verifying the Fix

After updating the certificates, test the resolution by attempting the operation that previously failed. Run sudo apt update or try adding the repository again using add-apt-repository. If the configuration is correct, the commands should complete without SSL errors. If you still encounter issues, verify that the certificate was correctly copied and that there are no syntax errors in the file. You can also check the APT logs for more detailed error messages. Additionally, ensure that your WSL instance is up to date, although this specific fix applies to all modern versions of Ubuntu on WSL. For users who frequently switch between networks or need to manage their WSL distribution differently, understanding the underlying infrastructure is helpful. If you ever need to reset your environment or migrate your setup, knowing how to handle core components like certificates ensures smoother transitions. For broader context on managing your WSL instance, such as locating your installation files or dealing with disk usage, refer to our guide on Ubuntu WSL Install Location: Where to Find It?.

Frequently Asked Questions

Why does this work in Windows but not WSL?

Windows maintains its own separate certificate store managed by the operating system, which often includes corporate CAs by default. WSL runs a Linux kernel that uses the Unix-style trust store located in /etc/ssl/. These two stores do not sync automatically, requiring manual intervention for Linux-specific tools.

Can I use environment variables to bypass the certificate check?

While you can set CURL_CA_BUNDLE or REQUESTS_CA_BUNDLE to point to your certificate, this is not recommended for system-wide package management. Modifying the system trust store via update-ca-certificates is the permanent and correct solution that affects all applications, including APT and Git.

What if my company uses multiple interception proxies?

If your network routes traffic through different proxies depending on the destination, you may need to import multiple certificates. Simply copy each additional .crt file into the /usr/local/share/ca-certificates/extra/ directory and run sudo update-ca-certificates again after each addition.

Does this fix apply to other Linux distributions in WSL?

Yes, this method works for any Linux distribution running in WSL, such as Debian, Kali, or Fedora. Each distribution has its own trust store, so you must perform these steps individually for each distro you use that requires HTTPS access.

How do I remove the custom certificate later?

To remove the certificate, simply delete the corresponding .crt file from /usr/local/share/ca-certificates/extra/ and run sudo update-ca-certificates again. This will remove the certificate from the active trust store, reverting the system to its previous state.