Certificate Could Not Be Verified
Severity: High
Last updated August 11, 2026.
What it means
We could not verify this site's certificate against the trust store browsers and operating systems use, so visitors may see a security warning. This is a catch-all verification failure raised when the certificate problem doesn't match one of Nivaronix's more specific checks (expired, self-signed, hostname mismatch, incomplete chain, or untrusted CA).
Why it matters
A certificate that fails standard trust-store verification produces the same outcome for visitors regardless of the exact underlying cause: browsers block or warn before the page loads, and non-browser clients (apps, API callers) typically fail the connection outright.
What Nivaronix checks
Nivaronix performs a standard TLS handshake with certificate verification enabled, the same as a browser would. When verification fails for a reason outside its more specific categories, it records the underlying OpenSSL verification error as evidence. This is a certificate-trust check, not a scan for server-side vulnerabilities.
Example evidence
Illustrative example, not a live scan result. Run the checker below to see your own domain's actual status.
Illustrative example only — not a live scan result.
URL: https://example.com
TLS handshake: failed during certificate verification
OpenSSL verification code: 27 (CERT_NOT_YET_VALID)
Status: COULD NOT BE VERIFIEDHow to fix it
- Review your certificate installation with your provider.
- Reinstall the certificate together with its intermediate bundle rather than the leaf certificate alone.
- Confirm the certificate's validity window (not-before and not-after dates) and issuer chain are what you expect — a certificate installed early, or from an unexpected reissue, can trigger this before it's obviously "expired" or "self-signed".
How to verify the fix
Re-run the SSL/TLS checker against the domain, or run `openssl s_client -connect hostname:443 -servername hostname` and read the verification result it reports directly.
FAQ
Why isn't this reported as expired, self-signed, or one of the other specific findings?
Because the verification failure Nivaronix observed didn't match one of those more specific categories — this finding is the catch-all for a certificate that fails standard trust-store verification for a reason outside expired, self-signed, hostname mismatch, incomplete chain, or untrusted CA. The recorded OpenSSL verification error is the actual evidence of what went wrong.
What does an OpenSSL verification code actually tell me?
It's the specific numeric reason the TLS handshake's certificate check failed — for example, code 27 (CERT_NOT_YET_VALID) means the certificate's start date is in the future relative to the checking client's clock. Looking up the specific code returned narrows the cause far faster than guessing from symptoms alone.
Could this be a false positive caused by clock skew rather than my certificate?
Yes — a CERT_NOT_YET_VALID or expired-looking result can come from the verifying client's own system clock being wrong, not an actual problem with the certificate. Confirm the server's own clock is correct via NTP before assuming the certificate itself needs replacing.
Is this the same thing as a browser's 'Your connection is not private' warning?
It's the same category of failure — both mean the certificate didn't pass standard trust-store verification — but a browser warning is one specific client's interpretation, while this finding is Nivaronix performing the same handshake and reporting the underlying verification error directly, which is usually more diagnostic than the browser's generic warning text.
Check your certificate now
Free, no signup required.