Record the exact hostname, client/runtime and error. Check whether a corporate proxy or private CA is intentionally involved. Do not paste private keys, tokens or authenticated request bodies into diagnostics or support messages.

1. Confirm system time and synchronization. Compare the certificate validity dates with the actual clock rather than only the displayed timezone.
2. Verify DNS reaches the intended endpoint and the request uses the certificate hostname. An IP-address request can fail hostname validation even when the service certificate is otherwise correct.
3. Inspect the served chain with a trusted diagnostic client. With OpenSSL s_client, supply the intended server name for SNI and enable the relevant verification options; a displayed connection alone does not mean validation passed.
4. Compare the failing application's trust store with the system store. Java, containers and bundled runtimes can use separate CA bundles that need their own supported update process.
5. For a legitimate private CA, verify its identity through an independent trusted channel and install it using the distribution/runtime-supported mechanism. Do not promote an arbitrary website leaf certificate to a globally trusted root.
6. Retest with normal verification enabled and confirm the expected peer identity and chain.

Run this from the Linux system that reports the TLS error. Replace example.com with the hostname used by the application. OpenSSL reads the presented certificate chain and verifies the hostname; it does not disable certificate checking to force a connection.

date -u
openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com -verify_return_error </dev/null

Read the result: Compare any certificate validity error with the UTC clock. A missing issuer or trust error can involve an incomplete server chain or this machine's CA store. A name mismatch means the certificate does not cover the requested name, even if its expiry date is still valid.

OpenSSL and the application can use different trust stores, so follow up in the actual application runtime. Preserve the exact verification error. Do not solve the problem by enabling insecure mode in curl or turning off peer verification in production code.

They can use different trust stores, proxies and cached intermediates. Compare the actual client environment and validation error rather than assuming the browser result proves every client is configured correctly.

Check the original application succeeds without insecure flags and that unrelated TLS destinations still validate. Record any private trust anchor and its owner/expiry. Ensure the server sends required intermediate certificates rather than forcing every client to work around an incomplete chain.

If only one runtime fails, inspect its CA bundle, proxy settings and supported protocol policy. If the certificate is expired or for another name, repair the server certificate or endpoint selection. Do not weaken global cryptographic policy or disable verification to accommodate an unexplained failure.

• Verifying Linux time synchronization and timezone
• Separating DNS failure from network failure on Linux
• Diagnosing a Linux package repository signature failure
• Fixing an incomplete certificate chain

• Ubuntu: Troubleshooting TLS SSL
• docs.openssl.org: Openssl S Client
• Ubuntu: Install A Root Ca Certificate