AI Coding Tool SSL Certificate Error: 6 Tested Fixes

Overview

You open your AI coding tool, type a prompt, and get slapped with an SSL certificate error instead of a completion. The tool can’t establish a secure connection to its API endpoint — no TLS handshake, no code suggestions.

This hits developers behind corporate firewalls most often, but it also shows up after OS upgrades, on fresh installs, and when certificates expire. The error appears across Cursor, GitHub Copilot, Continue, Cline, and virtually any tool that calls an HTTPS API.

This article covers 6 tested fixes, ordered from most common cause to edge cases.

What Causes This Error

AI coding tools connect to remote APIs (OpenAI, Anthropic, custom endpoints) over HTTPS. The SSL/TLS handshake fails when your machine can’t verify the server’s certificate chain.

The exact error message varies by runtime and tool. Node.js-based tools (Cursor, Continue, most VS Code extensions) typically show:

Error: unable to verify the first certificate

Error: SELF_SIGNED_CERT_IN_CHAIN

Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE

Python-based tools surface it differently:

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate

requests.exceptions.SSLError: HTTPSConnectionPool(host='api.anthropic.com', port=443): Max retries exceeded (Caused by SSLError(SSLCertVerificationError))

Four root causes account for nearly every case:

1. Corporate proxy / TLS inspection. Your organization’s firewall terminates and re-signs HTTPS traffic with its own CA certificate. Your tool’s runtime doesn’t trust that CA.
2. Expired or missing CA certificates. The system CA bundle is outdated or incomplete.
3. Wrong system clock. Certificate validity is time-bound. A clock skew of even a few minutes can invalidate an otherwise valid cert.
4. Self-signed certificates on custom endpoints. If you’re pointing your tool at a local LLM server or self-hosted API proxy, the certificate isn’t signed by a public CA.

Solution 1: Fix Your System Clock

Wrong clock, invalid certificate. It’s the simplest cause and the easiest to miss.

Check your current system time against an NTP server:

# Linux
timedatectl status

# macOS
date -u

# Windows (PowerShell)
w32tm /query /status

If the time is off, sync it:

# Linux (systemd)
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd

# macOS
sudo sntp -sS time.apple.com

# Windows (PowerShell, run as admin)
w32tm /resync /force

After syncing, restart your IDE. Most AI coding extensions hold a persistent connection — they won’t pick up the time change until the extension or editor restarts.

Solution 2: Update CA Certificates

An outdated CA bundle can’t verify certificates signed by newer certificate authorities. This is common on minimal Docker images, older Linux installs, and machines that haven’t run system updates in a while.

Linux (Debian/Ubuntu):

sudo apt update && sudo apt install -y ca-certificates
sudo update-ca-certificates

Linux (RHEL/Fedora):

sudo dnf install -y ca-certificates
sudo update-ca-trust

macOS:

# If using Python from python.org installer
/Applications/Python\ 3.x/Install\ Certificates.command

# If using Homebrew Python
brew install ca-certificates

Node.js (for Cursor, Continue, VS Code extensions):

Node.js bundles its own CA store compiled into the binary. Updating system certificates alone won’t help. Point Node at the system store:

export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt

Add this to your shell profile (~/.bashrc, ~/.zshrc) so it persists.

For VS Code-based tools, you can also set it in settings.json:

{
  "http.systemCertificates": true
}

Solution 3: Configure Corporate Proxy Certificates

This is the most common cause for developers working in enterprise environments. Your corporate proxy performs TLS inspection — it decrypts HTTPS traffic, scans it, and re-encrypts it with the organization’s internal CA certificate. Your AI tool sees an untrusted certificate and refuses to connect.

Step 1 — Export the corporate CA from your browser:

In Chrome: navigate to any HTTPS site → click the padlock → “Connection is secure” → “Certificate is valid” → “Details” tab → select the root certificate → “Export.” Save as corporate-ca.pem.

Step 2 — Install it system-wide:

# Linux (Debian/Ubuntu)
sudo cp corporate-ca.pem /usr/local/share/ca-certificates/corporate-ca.crt
sudo update-ca-certificates

# macOS
sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain corporate-ca.pem

# Windows (PowerShell, run as admin)
Import-Certificate -FilePath .\corporate-ca.pem -CertStoreLocation Cert:\LocalMachine\Root

Step 3 — Configure Node.js (for VS Code extensions):

export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corporate-ca.crt

Step 3 (alt) — Configure Python (for CLI tools):

export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt

VS Code proxy settings:

If your proxy requires authentication, add these to VS Code settings.json:

{
  "http.proxy": "http://proxy.corporate.com:8080",
  "http.proxyStrictSSL": true,
  "http.systemCertificates": true
}

Solution 4: Fix Python SSL for CLI-Based Tools

Python-based AI tools (Claude Code, Aider, Open Interpreter) use their own SSL stack. If pip install works fine but the tool throws SSL errors, Python’s certificate bundle is the problem — not the system’s.

Diagnose first:

python3 -c "import ssl; print(ssl.get_default_verify_paths())"

This prints where Python looks for certificates. If the paths don’t exist or point to an empty file, that’s your issue.

Fix for pip-installed Python (most common):

pip install --upgrade certifi

Then verify the bundle exists:

python3 -c "import certifi; print(certifi.where())"

If using a corporate proxy, append your CA to certifi’s bundle:

CERTIFI_PATH=$(python3 -c "import certifi; print(certifi.where())")
cat corporate-ca.pem >> "$CERTIFI_PATH"

For conda environments:

conda install -c conda-forge certifi
conda config --set ssl_verify /path/to/corporate-ca.pem

Solution 5: Handle Self-Signed Certificates for Local LLM Endpoints

If you’re running a local LLM server (Ollama, llama.cpp, LM Studio) behind a reverse proxy with a self-signed certificate, your AI coding tool will reject the connection.

Two approaches — add the self-signed cert to your trust store, or generate a proper one.

Option A: Trust the self-signed certificate.

# Extract the certificate from the running server
openssl s_client -connect localhost:8443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -outform PEM > local-llm.pem

# Add to system trust (Linux)
sudo cp local-llm.pem /usr/local/share/ca-certificates/local-llm.crt
sudo update-ca-certificates

# Point Node.js at it
export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/local-llm.crt

Option B: Generate a proper certificate with mkcert.

mkcert creates locally-trusted certificates — no self-signed warnings.

# Install mkcert
brew install mkcert    # macOS
# or: sudo apt install mkcert  # Linux

# Create a local CA and install it in system trust stores
mkcert -install

# Generate a certificate for your local server
mkcert localhost 127.0.0.1 ::1

# Use the generated cert in your server config
# Output: localhost+2.pem and localhost+2-key.pem

Configure your reverse proxy or LLM server to use the mkcert-generated files. No additional client-side configuration needed — mkcert -install already added its CA to all local trust stores.

Solution 6: Tool-Specific Fixes

Some AI tools have their own SSL configuration quirks.

GitHub Copilot:

Copilot respects VS Code’s proxy settings. If you’ve configured http.proxy and the CA certificate but still get errors, restart VS Code completely — not just reload the window:

Ctrl + Shift + P → “Developer: Reload Window” is not enough. Quit and relaunch.

Cursor:

Cursor is an Electron app with its own Node.js runtime. Environment variables set in your shell may not propagate to Cursor launched from a desktop shortcut. Launch it from the terminal instead:

NODE_EXTRA_CA_CERTS=/path/to/ca.pem cursor

Or on macOS:

NODE_EXTRA_CA_CERTS=/path/to/ca.pem open -a Cursor

Continue (VS Code extension):

Continue lets you set a custom CA path directly in its config file (~/.continue/config.json):

{
  "requestOptions": {
    "caBundlePath": "/path/to/ca-certificates.crt"
  }
}

Claude Code (CLI):

Claude Code uses Node.js under the hood. The NODE_EXTRA_CA_CERTS variable works:

export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt
claude

Still Not Working?

If none of the above fixes resolve the error:

1. Test the connection directly to isolate whether the issue is your tool or your network:

# Test with curl (uses system certificates)
curl -v https://api.openai.com/v1/models 2>&1 | grep -i "ssl\|certificate"

# Test with OpenSSL
openssl s_client -connect api.anthropic.com:443 -servername api.anthropic.com

1. Check if a VPN is interfering. Some VPN clients install their own CA certificates and proxy settings. Disconnect the VPN and test.

2. File an issue with your specific tool. Include the exact error message, your OS version, runtime version (node --version or python3 --version), and whether you’re behind a proxy. Relevant issue trackers:

3. Cursor: forum.cursor.com
4. GitHub Copilot: github.com/orgs/community/discussions
5. Continue: github.com/continuedev/continue/issues

$ openssl s_client -connect api.openai.com:443 2>/dev/null | head -5
CONNECTED(00000003)
depth=2 C=US, O=DigiCert Inc, CN=DigiCert Global Root G2
verify return:1
depth=1 C=US, O=DigiCert Inc, CN=DigiCert G5 TLS RSA4096 SHA384 2021 CA1
verify return:1

If openssl connects fine but your tool doesn’t, the problem is in the tool’s runtime certificate configuration — not your network. Go back to Solution 2 or 3.

FAQ