Many website administrators still encounter a frustrating problem after deploying HTTPS: browsers display error messages such as "This connection is untrusted," "Invalid certificate," and "Website's security certificate is untrusted." For ordinary users, these messages indicate potential risks; however, for developers and operations personnel, they often signal configuration errors or abnormal certificate chains. To completely resolve this issue, it's essential to understand the principles of certificate trust mechanisms, identify possible root causes, and implement targeted remediation measures.

　　When a browser establishes an HTTPS connection with a website, it first verifies the certificate's legitimacy through the TLS handshake process. This process includes verifying whether the certificate was issued by a trusted authority, whether it has expired, whether it matches the currently accessed domain name, and whether an intermediate certificate chain exists. If any step fails, the browser marks the website as "untrusted." This doesn't necessarily mean the website has been hacked; it's usually due to a verification interruption caused by configuration, issuance, or compatibility issues. The most common causes include: an untrusted certificate issuing source, an incomplete certificate chain, an expired certificate, a mismatch between the domain name and certificate, an outdated root certificate, or an outdated trust store on the client system.

　　The most common reason is that the website uses a self-signed certificate. A self-signed certificate is one generated and signed by the website administrator without verification by any recognized Certificate Authority (CA). While convenient in testing environments, browsers do not trust such certificates because they lack a trusted root source. Users will typically receive a warning page stating, "This website's certificate was not issued by a trusted authority." If the website is only used on an intranet or development environment, this can be resolved by manually importing the self-signed certificate into the system or browser. However, for publicly accessible sites, certificates issued by a legitimate CA must be used; otherwise, the browser will not trust the certificate.

　　Another common reason is an incomplete certificate chain. A certificate system consists of a root certificate, intermediate certificates, and a server certificate. When returning a certificate, the server must provide a complete chain of intermediate certificates; otherwise, the browser will not be able to trace back to the root certificate from the server certificate during verification. Modern browsers may automatically complete the chain, but older systems or some mobile devices will not, resulting in an "untrusted certificate" message. This can be checked using the OpenSSL command-line tool.

openssl s_client -connect example.com:443 -showcerts

　　　　After execution, if you see information like "Verify return code: 21 (unable to verify the first certificate)" at the end of the output, it means the server did not send the intermediate certificate correctly. The solution is to download the corresponding intermediate certificate from the CA's website and concatenate it with the main certificate into a complete file.

cat example.crt intermediate.crt > fullchain.pem

　　This file is then used in server configurations, such as Nginx:

ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/example.key;

　　Once the browser has fully received the trust chain, the verification error will automatically disappear.

　　Certificate expiration will also result in an "untrusted" status. Each certificate has a specific expiration date; once expired, even a legitimate certificate will be considered invalid. The browser will display a "certificate expired" or "certificate no longer valid" message. Many administrators mistakenly believe that certificate renewal is automatic and therefore ignore failure notifications until users report access problems. It is recommended to use automation tools such as Certbot in conjunction with Let's Encrypt for periodic renewal and to add a scheduled check command to the system.

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

　　This command outputs the certificate's start and expiration times, which can be used in conjunction with a Cron scheduled task for daily checks. An alert email is triggered once the remaining days fall below a threshold, thus preventing expiration risks.

　　Another easily overlooked reason is a mismatch between the certificate domain name and the actual access address. For example, if a certificate is issued to www.example.com, but the user accesses example.com, the browser will report a "certificate does not match hostname" error. This problem is particularly common when deploying with multiple domains or subdomains. The solution is to select a SAN certificate that supports multiple domains when applying for the certificate, or to enable a wildcard certificate *.example.com to cover multiple subdomains. Simultaneously, the server configuration should ensure that the server_name matches the certificate; otherwise, Nginx or Apache will return the default virtual host certificate, causing confusion.

　　Sometimes, incorrect certificate configuration order can also cause verification failures. Administrators may mistakenly place the private key file in the certificate field or reverse the concatenation order. The correct approach is: the first line should be the server certificate, the second line should be the intermediate certificates, and the root certificate does not need to be concatenated (the browser already has it). Incorrect concatenation order can cause browsers to misinterpret the certificate chain, resulting in a "unable to establish a secure connection" error. Therefore, after modifying the configuration, it is essential to re-verify the chain's integrity using OpenSSL tools or online verification platforms (such as SSL Labs).

　　For some internal corporate websites, certificates issued by the company's own CA may be used. These certificates are not trusted by external browsers by default, thus displaying an "untrusted" message. The solution is to import the company CA's root certificate into the client system. For Windows systems, a certificate management tool can be used with the following command:

certutil -addstore root companyCA.crt

　　For macOS, you can import the certificate using Keychain Access. For Linux, place the root certificate in `/usr/local/share/ca-certificates/` and execute `update-ca-certificates`. After completion, all websites signed with this certificate will be trusted locally.

　　Another scenario is that the CDN or proxy layer certificate is inconsistent with the origin server certificate. For example, the origin server has deployed a new certificate, but the CDN caches an older version. When the browser accesses the site, it will obtain an expired or incorrect certificate from the CDN, naturally resulting in an untrusted warning. The solution is to log in to the CDN console, manually refresh the certificate, or re-upload the latest version, and ensure that the CDN nodes are synchronized with the origin server certificate.

　　It's worth mentioning that some websites incorrectly mix HTTP and HTTPS resources, causing some pages to load unencrypted content. Although the overall connection is valid, the browser will still display a "Some content is insecure" warning. This should be addressed by changing all resource links to HTTPS in the HTML or application configuration, or by using relative paths to automatically inherit the protocol. If using Nginx, you can enable the following header to force the browser to use secure resources:

add_header Content-Security-Policy "upgrade-insecure-requests";

　　This way, even if an HTTP link exists on the page, the browser will automatically replace it with an HTTPS request, thus avoiding security warnings.

　　After troubleshooting the above issues, if you still receive an "Untrusted" message, you can further verify whether the server has correctly loaded the certificate using the following command:

sudo nginx -t
sudo systemctl reload nginx

　　Or use it in an Apache environment:

apachectl configtest
systemctl restart apache2

　　These commands verify the correctness of configuration syntax and paths, preventing the referencing of incorrect files.

　　In summary, the "SSL certificate is untrusted" message is not a single problem, but rather a result of multiple factors including the issuing authority, certificate chain, expiration status, domain name mismatch, client compatibility, and configuration errors. The solution should start with the trust mechanism, systematically checking each step: first, confirm the certificate source is trustworthy; second, ensure the chain is complete; third, check for expiration or domain name mismatch; and finally, verify the client environment and CDN layer synchronization status. For operations teams, the best practice is to use automated detection scripts and third-party detection platforms for dual verification before deployment, test availability immediately after each certificate renewal, and keep the system updated.