Reproduce the actual connection
Record the hostname, port, affected client and time. A browser may have cached an intermediate certificate that a new client lacks, so different clients can report different results. The certificate shown by a CDN edge may also differ from the certificate served by the origin.
Inspect the endpoint with the correct server name indication, for example:
openssl s_client -connect example.com:443 -servername example.com -showcerts
Replace example.com with the authorized hostname. This shows certificates presented by the server; it does not by itself prove every client trusts the chain. Avoid sending credentials while testing.
Compare the chain and hostname
Check the leaf certificate's validity dates and names, the served intermediate certificates and the client's trust store. A missing intermediate, wrong virtual host, expired certificate or stale trust store can produce similar errors. Follow the issuing authority's instructions for the correct chain and server software.
Do not install an unrelated root certificate merely to make one client pass, and do not turn off certificate verification in application code. Those changes can hide a real identity problem.
Retest the affected path
After updating the server's certificate bundle or configuration, validate syntax and reload according to the platform's procedure. Recheck the public hostname with SNI, the affected client and any internal origin path separately. Document the renewal process so automation deploys the complete chain next time.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.