Era Host hosting
EraHost – Free Domain, Cheap Hosting!
Client Area
Support 24/7
Menu

Fixing depth_zero_self_signed_cert Error in SSL/TLS

3 min read
14.04.2025

What Does depth_zero_self_signed_cert Mean?

The error occurs when a server presents a self-signed certificate, and the client does not trust it because there is no certificate authority (CA) verifying it.

SSL/TLS depth_zero_self_signed_cert
Self-signed at depth 0 — only client trust decision can resolve.

For the git-specific variant and related certificate topics, see depth_zero_self_signed_cert in cPanel for Git Operations and What is _globalsign-domain-verification?.

Common Causes:

  • The server uses a self-signed SSL certificate.
  • The certificate is missing in the trusted certificate store.
  • Wrong certificate configuration on the server.
  • The client is not set to trust self-signed certificates.

Verify the SSL Certificate

Run:

openssl s_client -connect yourdomain.com:443 -showcerts

Expected output (if self-signed):

verify error:num=18:self-signed certificate
verify return:1
verify error:num=19:self-signed certificate in certificate chain
verify return:1

If you see depth=0, it means the certificate is not trusted.

Linux VDS
High performance for your projects
  • Root access and flexible setup
  • Control panel
  • NVMe disks
  • DDR5
Linux VDS

Fixing the Issue Based on Your Use Case

If Using a Self-Signed Certificate on a Server

Solution: Add the certificate to the system's trusted store.

For Debian/Ubuntu

sudo cp your_certificate.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

For CentOS/RHEL

sudo cp your_certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Restart your server:

sudo systemctl restart apache2

or

sudo systemctl restart nginx

If You Want to Ignore Self-Signed Certificate in a Client

For curl

Run:

curl -k https://yourdomain.com

-k or --insecure tells curl to ignore SSL verification.

For Node.js

Set:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Not recommended for production (security risk).

For Git

If you see:

fatal: unable to access 'https://yourdomain.com/repo.git/': SSL certificate problem: self signed certificate

Run:

git config --global http.sslVerify false

or add the certificate manually:

git config --global http.sslCAInfo /path/to/certificate.crt

If You Need a Valid SSL Certificate

Instead of using a self-signed certificate, get a free SSL certificate from Let's Encrypt.

For Apache

sudo apt install certbot python3-certbot-apache
sudo certbot --apache

For Nginx

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx

Summary of Fixes

Issue Fix
Self-signed certificate error Add certificate to trusted store (update-ca-certificates)
Ignoring self-signed cert in curl Use curl -k
Ignoring self-signed cert in Git Use git config --global http.sslVerify false
Get a valid certificate Use Let's Encrypt with certbot

Now you know how to fix depth_zero_self_signed_cert for different scenarios!

Frequently asked questions
OpenSSL verifies cert chains from leaf up to root. Depth 0 is the server's own certificate. Depth 1 is the intermediate that signed it. Root CA is the top. Self-signed at depth 0 means the server cert isn't signed by anyone — it signed itself. That's only trusted if you explicitly trust it via your client's CA store.
Internal development, automated testing, isolated lab networks. Avoid for production — even internal services should use a real CA (Let's Encrypt for internet-facing, or a private CA you trust at the system level). "It's internal" isn't safety; anyone on your LAN seeing self-signed prompts is being trained to click through cert warnings.
certbot or acme.sh — install on the server, run with the domain name, automatic certificate issuance via HTTP-01 challenge. Free, auto-renews via cron. The big requirement: domain resolves to your server publicly (needed for HTTP-01) and port 80 reachable. For internal services, DNS-01 challenge works without public reachability.
Don't disable verification globally (DANGEROUS — every TLS connection from that process is now vulnerable). Add the specific self-signed cert to a custom CA bundle for that one client/repo. curl: `--cacert /path/to.crt`. Python requests: `verify='/path/to.crt'`. Per-cert trust scales; global verification-off doesn't.
Related articles
Fixing depth_zero_self_signed_cert in cPanel with a Self-Signed Certificate
Fixing depth_zero_self_signed_cert in cPanel for Git Operations
Fixing session_start(): Permission Denied (13) in XAMPP — SELinux/AppArmor Restrictions