How to Fix CERTIFICATE_VERIFY_FAILED When Using HTTPS Through a Proxy

Understanding CERTIFICATE_VERIFY_FAILED When Using a Proxy

The CERTIFICATE_VERIFY_FAILED error occurs when an application cannot validate the certificate of the TLS endpoint under the applicable policy. When accessing HTTPS through a proxy, the cause may lie with the destination server, the proxy, the trusted certificate store, or the application's configuration.

The correct solution is not to disable certificate verification, but to identify the endpoint being validated, inspect the certificate chain, and provide the appropriate source of trust. This preserves both connection encryption and the ability to authenticate the server's identity.

How Does a Proxy Affect TLS Verification?

Proxies That Forward CONNECT Tunnels

With an HTTP proxy that uses CONNECT, the proxy establishes a tunnel to the destination server. If neither the proxy nor another intermediary performs HTTPS inspection, the TLS session is established between the application and the destination server; the proxy does not replace the website's certificate.

In this case, do not assume that the application needs the proxy's CA certificate. The error may be caused by a missing intermediate certificate in the server's certificate chain, an outdated CA store, an incorrect system clock, or a hostname mismatch.

Proxies with HTTPS Inspection

In some enterprise networks, proxies are configured by administrators to inspect HTTPS traffic. The device terminates the application's TLS connection and then establishes a separate TLS connection to the destination server.

The application now receives a certificate issued by the organization's CA infrastructure. For validation to succeed, the application must trust the organization-approved CA, and the certificate must still meet requirements for the domain name, validity period, and chain of trust.

The Connection to the Proxy Itself Also Uses TLS

If the application supports connecting to the proxy over HTTPS, there may be one TLS layer to the proxy and another TLS layer to the destination server. These two layers may use different CA configurations.

Therefore, read the error to determine which certificate is being rejected. Adding a CA for the connection to the website will not necessarily resolve a certificate validation error involving the proxy itself.

Read the Error Message Before Changing the Configuration

CERTIFICATE_VERIFY_FAILED is a general message. The accompanying description often helps classify the cause:

• Unable to get local issuer certificate: the application cannot build a chain of trust to an accepted CA; a root CA or intermediate certificate may be missing.
• Self-signed certificate in certificate chain: the chain contains a self-signed certificate, but an appropriate trust relationship has not been established.
• Certificate has expired: a certificate in the chain has expired, or the client's clock is incorrect.
• Hostname mismatch: the requested hostname does not match the identity recorded in the certificate.

When recording an error, include the application name, TLS library version, destination address, proxy type, and complete message. Do not include proxy passwords, tokens, or credentials in shared logs.

Identifying the Source of SSL Errors When Using a Proxy

Compare Under the Same Runtime Conditions

If network policy permits, compare direct and proxied connections to the same domain using the same application in the same environment. If the direct connection works but the proxied connection fails, investigate the certificate being presented and the proxy configuration.

The fact that a browser can open the website does not prove that the application has all the necessary CAs. Browsers, Python, Java, and containers may use different trust stores.

Inspect the Certificate Actually Received

Use an organization-approved TLS diagnostic tool to inspect the subject, issuer, validity period, and certificate chain. With an OpenSSL version that supports CONNECT proxies, you can use a command such as openssl s_client -proxy proxy.example:8080 -connect service.example:443 -servername service.example -showcerts.

This example is intended for an HTTP proxy that supports CONNECT; proxy authentication capabilities depend on the tool. Displaying certificates does not by itself prove that the connection is valid, because diagnostic tools may continue running after reporting a validation error.

If the issuer belongs to internal infrastructure, confirm it with your administrators. If the certificate does not match the expected configuration, investigate before adding any source of trust.

Obtaining and Validating Proxy CA Certificates Correctly

Proxy CA certificates should be obtained through official administrative channels: a device management system, an internal configuration repository, or the team responsible for infrastructure. Do not download a certificate from an unknown source and install it merely to make the connection work.

Before using it, check the following:

• The subject and issuer names match the organization's documentation.
• The certificate is still valid and its intended use is appropriate.
• The certificate has CA attributes consistent with the infrastructure's design.
• The fingerprint has been verified through an independent, trusted channel.
• The file is in a format supported by the application, such as PEM.

Only the public certificate needs to be distributed; do not request or copy the CA's private key. Also, do not automatically add the destination server's certificate to the CA store as a substitute for fixing the chain of trust.

Configuring the Trust Store for the Right Application

The Operating System's Certificate Store

If organizational policy requires multiple applications to trust an internal CA, administrators can distribute the CA to the operating system's trust store. On Linux, the process depends on the distribution; on Windows and macOS, the correct user or system-wide scope must be selected.

However, some runtimes do not automatically use this store. After installation, you must still check which CA source the application is reading.

A Dedicated CA Bundle for the Application

A dedicated CA bundle is suitable when only one service needs to trust an internal CA. The file should be centrally managed, have appropriate access permissions, and contain all the CAs required for the application's connection scope.

If the library treats a custom bundle as a replacement source, a file containing only the internal CA may cause connections to public websites to fail. Confirm the library's behavior before deployment.

Fixing CERTIFICATE_VERIFY_FAILED in Python

Applications Using Requests

With Requests, you can specify the CA bundle path using the verify parameter, for example requests.get(url, proxies=proxy_config, verify='/app/certs/company-ca-bundle.pem'). This provides a source of trust while keeping certificate verification enabled.

The REQUESTS_CA_BUNDLE environment variable can also be used to specify the bundle. Make sure the process actually receives this variable; service environments, background jobs, and terminal sessions may differ.

If the application implements its own request-processing flow or a custom Session, check how environment settings are loaded. Do not assume that setting a variable in the operating system means every piece of code will use it.

Applications Using ssl or Other Libraries

With the standard library, you can create a context using ssl.create_default_context(), then add a CA using load_verify_locations(cafile=...). This allows additional CAs to be loaded into a context that already has the default verification settings.

Some libraries support SSL_CERT_FILE or SSL_CERT_DIR, but their behavior depends on the runtime and how the library initializes TLS. Check the relevant documentation rather than applying one variable to every Python application.

Avoid directly editing CA files in a library's installation directory: changes may be lost during updates and can be difficult to manage across environments.

Considerations for curl, Node.js, and Java

• curl: the --cacert option specifies CAs for the TLS connection to the destination server. When using an HTTPS proxy, --proxy-cacert is used to validate the TLS layer to the proxy, if supported by the build.
• Node.js: NODE_EXTRA_CA_CERTS can add CAs when the process starts. A ca setting passed directly to a connection may change the CA source used.
• Java: check which truststore the JVM or application actually uses. Installing a CA in the operating system does not guarantee that Java will automatically recognize it.

Regardless of the tool, keep hostname and certificate chain verification enabled. Trusting a CA does not make a certificate with the wrong domain name valid.

Containers and CI/CD Environments Require Separate Configuration

Containers usually have CA stores that are independent of the host running them. Therefore, installing a certificate on the host is not enough; the image or deployment configuration must provide the CA to the process inside the container.

In CI/CD, check the file paths, read permissions, execution account, and environment variables for the specific step that fails. A CA being present during the image build does not mean it remains in the final runtime image.

A public CA certificate is not a secret key, but its integrity is critical. Manage its source, version, and replacement schedule to avoid using a CA that has expired or is no longer approved.

Verifying After Configuration Changes

After updating the source of trust, rerun the request in the exact environment that previously reported the error. The result should demonstrate that the connection succeeds with TLS verification still enabled, not merely that an HTTP response is received.

• Confirm that the certificate matches the requested domain name.
• Check that the application has read the correct bundle or truststore.
• Compare the issuer against the approved proxy design.
• Test the necessary destinations to detect missing public CAs.
• In an authorized test environment, confirm that the application still rejects invalid certificates.

If the error persists, continue checking the intermediate certificate chain, system clock, proxy configuration, and actual CA source. Do not add large numbers of unverified certificates.

Conclusion

Resolving CERTIFICATE_VERIFY_FAILED when using HTTPS through a proxy starts with identifying the correct TLS layer and the reason validation failed. A sustainable solution is to fix the certificate chain, distribute approved CAs, and correctly configure the application's trust store.

When sources of trust are clearly managed and results are verified in the actual environment, applications can operate through a proxy without sacrificing the ability to authenticate the identity of the HTTPS connection.