Fix TLS Self-Signed Certificate in Certificate Chain Error (2026)

The x509: certificate signed by unknown authority error means the client (your browser or application) encountered a server’s TLS certificate and couldn’t verify its authenticity because it doesn’t trust the certificate authority (CA) that issued it. This usually happens when the server is using a self-signed certificate or a certificate issued by a private CA that isn’t recognized by the client’s system.

Here are the common causes and how to fix them:

1. Server Using a Self-Signed Certificate

Diagnosis: On the server, check the certificate file (e.g., server.crt or fullchain.pem). If it was generated using openssl req -x509 or a similar command without involving a trusted CA, it’s self-signed. You can also check the issuer and subject fields; for a self-signed certificate, they will be identical.

Fix:

• Option A (Recommended for production): Obtain a certificate from a trusted CA.

  • Command: Use certbot for Let’s Encrypt (free) or purchase a certificate from commercial CAs like DigiCert, Sectigo, etc.
  • Example (Certbot):

    sudo certbot --nginx -d yourdomain.com
    

    This command will automatically obtain, install, and renew certificates from Let’s Encrypt for yourdomain.com using the Nginx web server.
  • Why it works: Trusted CAs are pre-installed in the trust stores of operating systems and browsers. When a client sees a certificate signed by a recognized CA, it can verify the chain of trust back to a root certificate it already trusts.

• Option B (For development/testing only): Manually add the self-signed certificate to the client’s trust store.

  • Diagnosis: On the client machine, you need to find the self-signed certificate file. If you don’t have it, you can often extract it from the server.

    openssl s_client -showcerts -connect yourdomain.com:443 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/' > selfsigned.crt
    

    This command connects to the server and prints the certificate chain. awk extracts just the certificate part.
  • Fix (Linux/macOS):

    # For Debian/Ubuntu based systems
    sudo cp selfsigned.crt /usr/local/share/ca-certificates/yourdomain.crt
    sudo update-ca-certificates
    
    # For RHEL/CentOS/Fedora based systems
    sudo cp selfsigned.crt /etc/pki/ca-trust/source/anchors/yourdomain.crt
    sudo update-ca-trust extract
    
    # For macOS
    sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain selfsigned.crt
    

  • Fix (Windows): Double-click the .crt file, click "Install Certificate…", select "Local Machine" and "Place all certificates in the following store," then browse and select "Trusted Root Certification Authorities."
  • Why it works: By adding the self-signed certificate to the client’s trusted root store, you’re telling the client’s operating system to inherently trust this specific certificate, bypassing the need for a traditional CA chain. This is generally discouraged for production environments due to security risks.

2. Server Using a Certificate from a Private CA

Diagnosis: Inspect the certificate chain presented by the server. If the issuer of the server’s certificate is not a public CA (like Let’s Encrypt, DigiCert, GlobalSign), but rather an internal name (e.g., "MyCompany Internal CA"), then it’s issued by a private CA.

Fix:

• Option A (Recommended for internal networks): Distribute the private CA’s root certificate to all client machines.

  • Diagnosis: Obtain the root certificate of your private CA. This is usually a .crt or .pem file.
  • Fix: Deploy this root certificate to the trusted root CA store on all client machines (servers, workstations, mobile devices) that need to connect to your internal services. The process is identical to "Fix (Option B)" under the self-signed certificate section, but you’re adding the private CA’s root certificate, not the server’s leaf certificate.
  • Why it works: Similar to self-signed certificates, this explicitly trusts the entity that signed the server’s certificate, even if it’s not a public entity.

• Option B (Less common for internal, but possible): Configure the client to trust the specific intermediate CA.

  • Diagnosis: If the server is presenting a chain with an intermediate CA that is itself signed by a root CA you do trust, but the intermediate is missing from the server’s fullchain.pem, clients might fail.
  • Fix: Ensure the server’s certificate configuration includes the full chain, from the server’s leaf certificate up to the root CA. For Nginx, this means concatenating the server certificate and any intermediate certificates into a single file (e.g., fullchain.pem) referenced by ssl_certificate.
  • Why it works: The client needs the complete chain to trace the signature back to a root it trusts. If an intermediate is missing, the chain is broken.

3. Incorrect Certificate File on Server

Diagnosis: The server’s TLS configuration points to the wrong certificate file, or the file itself is corrupted or incomplete. Check the ssl_certificate directive in Nginx or SSLCertificateFile in Apache.

Fix:

• Command: Verify the path and integrity of the certificate file specified in your web server’s configuration.

  # Example for Nginx:
  sudo nginx -t # Checks syntax and config validity
  sudo cat /etc/nginx/ssl/yourdomain.crt # View the file content
  

  Ensure the file contains the correct certificate data, not just a private key or a CA bundle meant for a different directive.
• Why it works: The server must present the correct, complete certificate to the client for verification. If the wrong file is configured or the file is malformed, the client will receive unexpected data and fail verification.

4. Client System Time is Incorrect

Diagnosis: If the client’s system clock is significantly ahead or behind the server’s clock, a valid certificate might appear expired or not yet valid.

Fix:

• Command: Synchronize the client’s system time using NTP.

  # For systems using systemd (most modern Linux)
  sudo timedatectl set-ntp true
  sudo systemctl restart systemd-timesyncd
  
  # For older systems or macOS
  sudo ntpdate pool.ntp.org # Might need to install ntpdate
  # Or ensure Network Time is enabled in macOS System Preferences -> Date & Time
  

• Why it works: TLS certificates have validity periods (Not Before and Not After dates). Accurate time synchronization on the client is crucial for these dates to be evaluated correctly.

5. Certificate Revocation Check Failure (Less Common for Self-Signed)

Diagnosis: While less common for self-signed or private CAs unless they implement CRLs/OCSP, clients might attempt to check if the certificate has been revoked. If the revocation check fails (e.g., the CRL Distribution Point is unreachable), the connection may be terminated.

Fix:

• Option A: If using a private CA, ensure its CRL distribution points or OCSP responders are accessible to clients.
• Option B: For development/testing with self-signed certificates, you might disable revocation checks if the client software allows it, though this is a security risk.
• Why it works: Certificate revocation mechanisms allow CAs to invalidate certificates before their expiry date. If the client cannot perform this check, it might err on the side of caution.

6. Intermediate Certificate Missing on Server

Diagnosis: The server’s certificate is signed by an intermediate CA, but the intermediate certificate itself is not being sent by the server along with the end-entity certificate. The server might only be configured with its own certificate, not the full chain.

Fix:

• Command: Concatenate your server’s certificate and the intermediate CA certificate(s) into a single file. The order matters: server certificate first, then intermediate(s).

  cat yourdomain.crt intermediate.crt > fullchain.crt
  # Then update your web server config to point to fullchain.crt
  # Example for Nginx:
  ssl_certificate /etc/nginx/ssl/fullchain.crt;
  ssl_certificate_key /etc/nginx/ssl/yourdomain.key;
  

• Why it works: The client needs the entire chain of trust to verify the server’s certificate. If the intermediate certificate is missing, the client cannot link the server’s certificate back to a root CA it trusts.

The next error you’ll likely encounter is related to the private key not being found or being incorrect if the certificate file was indeed the wrong one.