Axioserror Self-Signed Certificate In Certificate Chain | Fixes

Axioserror Self-Signed Certificate In Certificate Chain Meaning And Root Cause

The message appears when Axios refuses an HTTPS request because it cannot build a trusted chain from the server certificate back to a known certificate authority during the TLS handshake on that connection.

Quick Context

A valid TLS chain usually links the site certificate to one or more intermediate certificates and then to a trusted root certificate. If any link in that chain is self-signed and not trusted locally, the chain breaks and Axios stops the request.

This error often shows up after you turn on HTTPS on a dev machine, switch a backend to a new SSL setup, or start calling an internal API behind a company proxy. The pattern is the same in each case: the TLS chain that the server presents does not match what your Node runtime or browser trusts.

Why Axios Hits A Self-Signed Certificate In Certificate Chain

Root Causes

Several common setups trigger this error. They all come down to one of two themes: the server sends a chain that clients cannot validate, or the client does not know about the certificate authority that issued the server certificate.

• Local HTTPS with a self-signed cert — Dev stacks that use tools like mkcert, OpenSSL, or Docker often serve APIs with a self-signed certificate that only exists on one machine.
• Internal corporate certificate authority — Many companies run their own CA for internal services. Browsers on managed laptops may trust that CA, while your Node process inside a container or on a new laptop does not.
• Missing intermediate certificates — The server sends only its leaf certificate and skips one or more intermediate certificates in the chain, so Axios cannot reach a trusted root.
• Expired or mismatched certificates — One item in the chain has expired, uses the wrong hostname, or was issued for a different purpose.
• HTTPS through a proxy — A TLS-inspecting proxy re-signs traffic with its own certificate, which looks self-signed unless its CA is installed in your trust store.

Each case creates the same result from Axios: the TLS handshake fails during certificate verification, so the promise rejects with a self-signed certificate message instead of application data.

Secure Ways To Fix The Error On A Node Backend

Main Goal

Fix the trust chain instead of turning TLS checks off. That gives you working requests and keeps protection against man-in-the-middle attacks.

Start With The Server Certificate Chain

When you control the API server, first check the certificate chain it presents. Tools such as SSL Labs or OpenSSL show whether all intermediates are present and whether any certificate has expired. If the chain is incomplete, reinstall the certificate bundle from your provider so that the server sends the full chain from leaf to root.

• Reinstall the full certificate bundle — Use the combined file from your certificate provider that includes the server certificate and intermediates in the right order.
• Restart the web server or reverse proxy — Apply the new bundle on Nginx, Apache, or your load balancer, then run another TLS test.
• Verify with a browser and with curl — Load the site in a browser and run a curl command to confirm the chain now looks correct before trying Axios again.

Trust An Internal Certificate Authority In Node

When the server uses a private or corporate CA, you need to teach Node about that CA. The safest approach is to add the CA certificate to a trust file and point Node to it instead of turning checks off in code.

• Export the CA certificate — Grab the root or intermediate CA certificate from your internal PKI portal or export it from a browser in PEM format.
• Store it in a shared location — Place the file somewhere your app container or host can read, such as /etc/ssl/certs/internal-ca.pem.
• Point Node to the CA with NODE_EXTRA_CA_CERTS — Start your app with a variable such as NODE_EXTRA_CA_CERTS=/etc/ssl/certs/internal-ca.pem node app.js. Node then merges that CA into its trust store.

With the CA trusted at the runtime level, Axios can keep its default TLS checks and still connect to your internal API. This pattern also works well inside Docker images, as long as you copy the CA file into the container and set the same variable in the start command.

Pass A Custom CA Directly To Axios

If you prefer to scope trust more narrowly, you can pass a custom HTTPS agent with a ca field to Axios instead of altering global Node trust.

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

const ca = fs.readFileSync('/etc/ssl/certs/internal-ca.pem');

const agent = new https.Agent({
  ca,
});

axios.get('https://internal-api.mycorp.test', { httpsAgent: agent })
  .then(res => {
    console.log(res.data);
  })
  .catch(err => {
    console.error(err.message);
  });
  

This setup limits the extra trust to calls that use that agent while leaving the rest of the process untouched.

Handling Local Self-Signed Certificates During Development

When you spin up a local HTTPS API with a self-signed certificate, the safest route is still to trust a local CA instead of turning checks off entirely.

• Generate a local CA and host certificate — Tools such as mkcert create a CA once and reuse it for all your local domains.
• Install the local CA into the OS trust store — Follow the mkcert instructions for your platform so that browsers and Node trust the same CA.
• Point your dev server at the mkcert host certificate — Configure your Node HTTPS server, reverse proxy, or Docker stack to use the mkcert-generated certificate files.

By treating your dev HTTPS stack like a small version of production, you avoid a habit of switching TLS checks off during local testing.

Handling Axios Self-Signed Certificate Errors In Frontend Projects

Browser Clue

When calls from a React or Vue app fail with a self-signed certificate message, the browser usually shows a TLS warning as well. The issue still lives in the backend or proxy while the log message appears in your frontend code.

Use A Dev Proxy For Local HTTPS APIs

Single-page app toolchains often ship with a dev proxy, which lets the browser talk to plain HTTP while the Node dev server handles HTTPS details. That keeps certificate handling in one place and avoids repeated TLS configuration on each client.

• Configure the proxy in your dev server — For Vite, that might be a proxy entry in vite.config.js that forwards /api calls to your HTTPS backend.
• Mark the proxy target as secure only in production — During local work you can set a flag that relaxes TLS checks for that proxy alone, while production builds call the real HTTPS endpoint directly.
• Keep proxy settings in stage config files — Store backend URLs and TLS flags in per-stage config files so that you never forget to switch back to strict checks.

When The Browser Sees A Company TLS Proxy

In some offices, a TLS-inspecting proxy inserts its own certificate. The proxy CA lands in the system trust store through device management, so browsers are happy but Node processes in containers may fail. In that case, export the proxy CA certificate and feed it to Node in the same way as any other internal CA.

The Axios setup on the frontend can stay simple in this scenario. Once the proxy CA sits in the trust store of the host and containers, Axios calls through fetch or XHR just work again.

Temporary Workarounds And Why They Are Risky

Short Warning

Many online threads suggest turning TLS checks off in Axios or Node to get past this error. That choice hides the message but opens a wide security gap.

Disabling TLS Checks In Node

Node lets you skip TLS verification globally with the variable NODE_TLS_REJECT_UNAUTHORIZED=0. A similar pattern appears in Axios when you pass an HTTPS agent with rejectUnauthorized: false.

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

const agent = new https.Agent({
  rejectUnauthorized: false,
});

axios.get('https://any-host.test', { httpsAgent: agent })
  .then(res => console.log(res.data))
  .catch(err => console.error(err));
  

That setting tells Node to accept any certificate chain, including chains controlled by an attacker. It removes one of the main protections that HTTPS gives you.

When A Temporary Bypass May Be Acceptable

During early debugging on a local machine with throwaway data, a quick bypass can help confirm whether the rest of the request logic works. Still, tie that bypass to a separate script or branch so that it never reaches shared code or production builds.

• Limit bypass code to local scripts — Keep the agent with rejectUnauthorized: false or the global Node flag inside a helper script that you do not commit.
• Add clear comments and safeguards — Label any bypass code as unsafe and add checks that guard against running it in shared stages.
• Remove bypass flags before merging — Treat this step like removing debug logs or test secrets.

Quick Reference For Fixing Axios Self-Signed Certificate Problems

Fast Scan

This table gives a snapshot of safe choices versus risky shortcuts for the most common Axios TLS setups.

Setup	Preferred Fix	Risk Level
Public API with bad chain	Reinstall full CA bundle on the server and retest	Low once fixed
Internal API with private CA	Add CA to Node trust store or pass CA to Axios agent	Low when CA file is secured
Local HTTPS dev server	Use a local CA tool such as mkcert and install its root	Low when dev CA stays private
Corporate TLS proxy	Export proxy CA and supply it through NODE_EXTRA_CA_CERTS	Low once hosts and containers share trust
Quick one-off debugging	Temporary rejectUnauthorized: false only in local helper code	High if it leaks into shared code

Practical Tip

When the same endpoint works in a browser but fails in Axios, grab the server certificate with a TLS inspection tool and compare chains. That small check tells you whether the gap sits in the server bundle, a missing private CA, or a proxy. With that clue, you can apply the narrowest fix instead of guessing from stack traces. This saves debugging time and keeps production logs far cleaner.

The Axioserror Self-Signed Certificate In Certificate Chain message looks noisy at first, yet it acts as a useful guardrail. Once you repair the TLS chain, add the right CA certificates, and keep temporary bypass flags out of shared code, Axios returns data again while HTTPS keeps doing its job for your Axios clients.