Why "Chain Trusted" can say No for a certificate that's actually fine

This tool validates the certificate chain against Node.js's default trust store — the same set of publicly trusted root CAs your browser and operating system also generally trust. A certificate signed by an internal/private CA (common for internal services, VPNs, and dev/staging environments) or a genuinely self-signed certificate will correctly show as untrusted here, because it isn't backed by a root in that public trust store — that's expected behavior, not a false positive, for exactly the environments where that's the intended setup. "Chain Trusted: No" means "not trusted by a public CA trust store," which is a different and narrower statement than "something is wrong with this certificate."

Why expiration and trust are checked as separate, independent facts

A certificate can be perfectly valid on one axis and fail on the other — a certificate from a fully trusted public CA that has simply expired, or a certificate that's well within its validity window but signed by an untrusted internal CA. Reporting these as two independent fields rather than collapsing them into a single pass/fail verdict is deliberate: knowing specifically which condition is the problem (expired vs. untrusted issuer vs. both) is exactly the information needed to know what actually needs fixing, whether that's renewing a certificate or adding a private CA to a trust store.