How to Fix Axios Self-Signed Certificate Errors [A Complete Guide 2026]

Verified by Priya Mervana, Verified Web Security Expert, SSLInsights.com - Last reviewed: June 2026 | Based on 10+ years of SSL/TLS implementation across web development and DevOps environments.

Quick Answer
Axios self-signed certificate error - a runtime error thrown when the Node.js HTTPS module rejects an SSL certificate not issued by a trusted Certificate Authority (CA). It manifests as SELF_SIGNED_CERT_IN_CHAIN, UNABLE_TO_VERIFY_LEAF_SIGNATURE, or DEPTH_ZERO_SELF_SIGNED_CERT. The root cause is almost always a missing or incorrect CA trust chain on either the client or server side.

How do you fix an Axios self-signed certificate error?

The correct production fix is to load your certificate's PEM file into Axios via httpsAgent with the ca option - this explicitly trusts the certificate without disabling all SSL verification. For development only, setting rejectUnauthorized: false bypasses validation entirely, but this creates a man-in-the-middle vulnerability and must never reach production. The fastest path to a permanent fix is replacing your self-signed certificate with a free CA-signed one from Let's Encrypt.

What Causes Axios self-signed certificate errors in Node.js?

Axios delegates HTTPS connections to Node.js's built-in https module, which validates every server certificate against a list of trusted Certificate Authorities. When a server presents a certificate it signed itself - rather than one issued by a recognized CA like DigiCert or Let's Encrypt - Node.js rejects the handshake and Axios throws one of three error codes:

These errors appear most often in local development servers, internal staging APIs, and Docker containers where certificates are auto-generated rather than CA-issued. Notably, Axios vs fetch behaves differently here - the native fetch API in Node 18+ also rejects self-signed certs, but its error message differs.

How Can I temporarily fix Axios SSL errors in development?

The fastest workaround for a Node.js axios certificate verify failed error during local development is to disable certificate verification for a specific request:

const https = require('https');
const axios = require('axios');

const agent = new https.Agent({
  rejectUnauthorized: false //  Development only
});

axios.get('https://your-local-api.com', { httpsAgent: agent })
  .then(response => console.log(response.data))
  .catch(error => console.error(error));

This works, but the rejectUnauthorized: false flag disables all certificate validation - meaning your application will silently accept expired, revoked, or spoofed certificates. For a marginally safer fallback, you can catch the specific error code before falling back:

axios.get('https://your-api.com')
  .catch(error => {
    if (error.code === 'DEPTH_ZERO_SELF_SIGNED_CERT') {
      const insecureAgent = new https.Agent({ rejectUnauthorized: false });
      return axios.get('https://your-api.com', { httpsAgent: insecureAgent });
    }
    throw error;
  });

In SSLInsights's work with Node.js development teams, the most common mistake is committing this workaround to a shared environment variable file - where it persists unnoticed into staging and production builds.

You can also set the environment variable globally for a Node.js process:

NODE_TLS_REJECT_UNAUTHORIZED=0 node your-script.js

Is it safe to disable SSL in Axios?

No. This approach is acceptable for isolated local testing on a machine you control. In any shared, staging, or internet-facing environment, it creates an undetectable vulnerability to certificate spoofing attacks.

How Do I fix Axios SSL errors in production? (The Correct Method)

For any environment beyond localhost, there are two approaches - one that trusts your specific certificate, and one that eliminates the problem permanently.

Option 1: Add the Self-Signed Certificate to Axios Trust Store

This is the right fix when you genuinely need to use a self-signed certificate - for example, internal microservices on a private network:

const fs = require('fs');
const https = require('https');
const axios = require('axios');

const cert = fs.readFileSync('./certs/your-cert.pem');

const agent = new https.Agent({
  ca: cert // Trusts ONLY this certificate
});

axios.get('https://your-internal-api.com', { httpsAgent: agent });

This is strictly more secure than rejectUnauthorized: false because it trusts one specific certificate rather than accepting any certificate. The certificate file path should come from an environment variable, not a hardcoded string.

Option 2: Replace the Self-Signed Certificate (Recommended)

The most permanent solution to axios self signed certificate in certificate chain errors is to stop using self-signed certificates. Let's Encrypt issues free, CA-signed certificates trusted by all major runtimes:

sudo certbot certonly --standalone -d yourdomain.com 

After issuance, configure your server to use the generated fullchain.pem and privkey.pem files. Axios will no longer throw certificate errors because the trust chain is complete.

For how to use a proper CA-signed certificate in Axios, you typically need no configuration at all - Node.js trusts Let's Encrypt certificates by default in all versions ≥12.

How Do I fix Axios certificate errors in React and Vite?

When developing a React application with Vite's dev server, the self-signed certificate error appears in the browser console because Vite proxies API requests through its own Node.js process. Fix it by configuring the proxy in vite.config.js:

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'https://your-api.com',
        changeOrigin: true,
        secure: false // Disables cert check for this proxy target only
      }
    }
  }
});

The secure: false option scopes the certificate bypass to Vite's proxy layer rather than your entire application. Your production build is unaffected, because Vite's dev server configuration is not included in build output. For a comparison of axios ssl error in TypeScript, the fix is identical - TypeScript types for https.AgentOptions fully support the ca and rejectUnauthorized fields.

For users working with self-signed certificates across environments, the SSL errors guide covers common certificate chain issues across servers and frameworks.

How Do I fix Axios Docker SSL certificate errors?

When Axios runs inside a Docker container and connects to a host with a self-signed certificate, the container's trust store does not include that certificate. The fix is to add the PEM file to the container's CA bundle during the build step:

COPY ./certs/your-cert.pem /usr/local/share/ca-certificates/your-cert.crt
RUN update-ca-certificates

This approach registers the certificate at the OS level, so all Node.js processes in the container trust it - including Axios - without any code changes. The certificate file must use the .crt extension in /usr/local/share/ca-certificates/ for update-ca-certificates to process it correctly.

For production Docker deployments, the better practice is to mount a properly issued CA-signed certificate into the container via a secrets manager (AWS Secrets Manager, HashiCorp Vault) rather than baking it into the image. To verify your certificate's chain of trust before deploying, use the SSL Checker Tool to confirm all intermediate certificates are correctly presented.

How Do I configure Axios globally to handle SSL certificates?

For applications making many HTTPS requests to the same self-signed endpoint, configure a default httpsAgent on the Axios instance rather than repeating it per request:

const https = require('https');
const axios = require('axios');
const fs = require('fs');

const agent = new https.Agent({
  ca: fs.readFileSync(process.env.SSL_CERT_PATH)
});

const apiClient = axios.create({
  baseURL: 'https://your-api.com',
  httpsAgent: agent
});

// All requests from apiClient use the custom agent
apiClient.get('/endpoint').then(/* ... */);

Using process.env.SSL_CERT_PATH keeps the certificate path configurable across environments without code changes. This pattern also works with axios add custom certificate authority in multi-service architectures where each service has its own certificate.

Understanding the broader context of self-signed certificate security helps teams decide when custom CA trust is appropriate versus when a public CA is required.

PRACTITIONER'S NOTE

After reviewing dozens of Node.js codebases at SSLInsights, I've found that rejectUnauthorized: false is rarely removed once added - it travels from a developer's laptop through CI to production without anyone flagging it because the application keeps working. The safest habit is to treat any occurrence of this flag as a failing test condition: write a lint rule or CI check that blocks this pattern from merging to any non-development branch. Explicitly trusting a specific PEM file with the ca option takes three extra lines and eliminates the security risk entirely. When in doubt, spend thirty minutes getting a Let's Encrypt certificate - the problem goes away permanently.

– Priya Mervana | Web Security Expert, SSLInsights.com

Frequently Asked Questions (FAQs)

What is the Axios self-signed certificate error and why does it happen?

Axios throws a self-signed certificate error when Node.js's HTTPS module cannot verify the server's SSL certificate against a trusted CA. The error codes include SELF_SIGNED_CERT_IN_CHAIN, DEPTH_ZERO_SELF_SIGNED_CERT, and UNABLE_TO_VERIFY_LEAF_SIGNATURE. It occurs on development servers, internal APIs, and staging environments where certificates were self-generated rather than issued by a recognized Certificate Authority like Let's Encrypt or DigiCert.

How do I disable SSL verification in Axios for local testing?

Pass { httpsAgent: new https.Agent({ rejectUnauthorized: false }) } as a config option to your Axios request, or set the NODE_TLS_REJECT_UNAUTHORIZED=0 environment variable before running your Node.js process. Both methods bypass all certificate verification and must be restricted to local development only - never committed to staging or production configurations.

Is it safe to set rejectUnauthorized false in Axios?

No. Setting rejectUnauthorized: false disables certificate validation entirely, making your application accept any certificate - including forged, expired, or revoked ones. This creates a direct vector for man-in-the-middle attacks. Use it only on a local machine you control, and only when connecting to a server you own.

What is the UNABLE_TO_VERIFY_LEAF_SIGNATURE error in Axios?

This error means the server's SSL certificate exists but Axios cannot verify its issuer because intermediate CA certificates are missing from the certificate chain. The server is presenting only the end-entity certificate, not the full chain. The fix is to configure the server to serve the full certificate bundle - typically a fullchain.pem file - rather than just the domain certificate.

How do I add a custom CA certificate to Axios?

Read the PEM file with fs.readFileSync('./your-cert.pem') and pass it to the ca field of https.Agent: new https.Agent({ ca: certBuffer }). Attach this agent to your Axios config via httpsAgent. This instructs Node.js to trust that specific certificate while continuing to enforce validation for all other HTTPS connections.

Why does Axios show DEPTH_ZERO_SELF_SIGNED_CERT specifically?

DEPTH_ZERO_SELF_SIGNED_CERT appears when the certificate at depth zero (the server's own certificate) is both the end-entity and its own issuer. In other words, the certificate chain has exactly one certificate and it is self-signed. This is the exact error thrown by development tools like mkcert when the generated certificate is not added to the system or application trust store. Verify your trusted Certificate Authority configuration to resolve it.

Final Thoughts

Axios self-signed certificate errors have a clear fix hierarchy: use rejectUnauthorized: false only for isolated local testing, pass an explicit ca certificate when you must trust a specific self-signed cert in a controlled environment, and replace self-signed certificates with CA-signed ones for anything accessible beyond localhost. The httpsAgent configuration pattern gives you precise, scoped control without disabling security globally.

Every production Node.js application making HTTPS requests should verify its certificate chain before deployment. The SSL Checker Tool confirms chain completeness in seconds.