Analysis and Solutions for OpenSSL Self-Signed Certificate Chain Error

Nov 20, 2025 · Programming · 12 views · 7.8

Keywords: OpenSSL | Self-Signed Certificate | Certificate Verification | SSL/TLS | CA Certificate

Abstract: This article provides an in-depth analysis of the "self signed certificate in certificate chain" error in OpenSSL, covering its causes, security implications, and solutions. By examining certificate verification mechanisms, it explains why self-signed certificates are untrusted and offers multiple validation and installation methods, including openssl verify commands, CA certificate installation, and code-level handling. With example code and security discussions, it helps developers fully understand SSL/TLS certificate verification processes.

Error Phenomenon and Background

When using OpenSSL APIs to validate a server certificate (self-signed), the error message error 19 at 1 depth lookup:self signed certificate in certificate chain appears. According to OpenSSL documentation, error code 19 corresponds to X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN, indicating that the certificate chain can be built using untrusted certificates, but the root certificate cannot be found locally.

Error Cause Analysis

The primary reason for this error is that self-signed certificates are untrusted by default. In the Public Key Infrastructure (PKI) system, certificate trust relies on trusted Certificate Authorities (CAs). Self-signed certificates are not signed by a third-party CA, so OpenSSL marks them as untrusted during verification. This mechanism serves as a security protection, as similar errors can arise from man-in-the-middle attacks, where an attacker uses a self-signed certificate to impersonate a legitimate server.

Security Implications and Risks

The self-signed certificate error alerts developers to potential security risks. In production environments, using self-signed certificates may lead to eavesdropping or tampering of communications. The referenced Postman CLI case further illustrates that even in toolchains, self-signed certificates require proper configuration to avoid verification errors. Internal SSL decrypting proxies (e.g., ssldecrypt.local) often use self-signed CAs, necessitating the installation of corresponding root certificates on clients.

Solutions and Practices

To resolve this issue, the self-signed certificate must be installed as a trusted certificate. If the certificate is signed by an untrusted CA, that CA's certificate must also be installed. Here are several common methods:

Method 1: Using OpenSSL Verify Command

Directly verify the certificate via command-line tools without installing the CA. Example command:

openssl verify -verbose -x509_strict -CAfile ca.pem certificate.pem

Here, ca.pem is the CA certificate file, and certificate.pem is the certificate to be verified. This method is suitable for temporary verification or testing environments.

Method 2: Installing CA Certificate

On Linux systems, copy the CA certificate to the system certificate directory (e.g., /etc/ssl/certs/) and run the update command:

sudo cp ca.pem /etc/ssl/certs/
sudo update-ca-certificates

On Windows systems, use the certutil tool:

certutil -addstore -f "Root" ca.pem

Method 3: Code-Level Handling

In some development environments, such as Node.js, certificate verification can be skipped by setting an environment variable:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Note that this method disables all SSL/TLS certificate verification and should only be used in development or testing environments, not in production.

Certificate Chain Building Principles

SSL/TLS certificate verification depends on the integrity of the certificate chain. The chain starts from the end-entity certificate, connects through intermediate certificates to the root certificate. During verification, OpenSSL attempts to build a complete chain. If a certificate in the chain is self-signed and not in the trusted root certificate store, it throws the X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN error. Proper configuration of the certificate chain bundle can prevent this issue.

Instance Analysis and Code Examples

Assume we have a self-signed server certificate server.crt and corresponding CA certificate ca.crt. The following C code example demonstrates how to use OpenSSL APIs for certificate verification:

#include <openssl/ssl.h>
#include <openssl/err.h>

int verify_callback(int preverify_ok, X509_STORE_CTX *ctx) {
    if (!preverify_ok) {
        int err = X509_STORE_CTX_get_error(ctx);
        if (err == X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN) {
            // Handle self-signed certificate error
            printf("Self-signed certificate in chain detected\n");
        }
    }
    return preverify_ok;
}

void load_trusted_certs(SSL_CTX *ctx, const char *ca_file) {
    if (SSL_CTX_load_verify_locations(ctx, ca_file, NULL) != 1) {
        ERR_print_errors_fp(stderr);
    }
}

In this code, the verify_callback function handles errors during verification, and load_trusted_certs loads trusted CA certificates.

Summary and Best Practices

Self-signed certificates are useful in development and testing but should be replaced with trusted CA-signed certificates in production. Properly handling certificate verification errors enhances application security and prevents potential network attacks. It is recommended to configure the certificate chain early in development and use tools like OpenSSL verify for regular validation.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.