TLS certificate best practices: validity, trust, and key strength

A TLS certificate proves your domain is really yours and lets browsers connect to it securely. When it expires, mismatches the hostname, or chains to a CA nobody trusts, every visitor sees a security warning. Here are the best practices for TLS certificates, and how SecRift scores yours across nine dimensions.

Most TLS problems people actually hit have nothing to do with cipher suites or exotic attacks. A certificate expires over a weekend because the renewal cron failed silently. A load balancer serves the wrong virtual host and presents a certificate for a completely different domain. An intermediate certificate gets dropped from the chain, so desktop browsers work but half the mobile apps refuse to connect. Or the certificate is flawless on paper - in date, trusted, correctly named - yet its own issuer revoked it weeks ago after a key compromise, and only a live query to the CA reveals it. The certificate is the foundation of trust in HTTPS, and when it breaks, it breaks loudly - for every visitor at once. This guide covers TLS certificate best practices and how SecRift scores yours across nine findings.

What is a TLS certificate?

A TLS certificate is a signed digital document that binds a public key to a hostname. When a browser connects to your site over HTTPS, the server presents this certificate to prove two things: that it holds the matching private key, and that a certificate authority (CA) the browser already trusts has vouched for the binding between that key and your domain name.

The format is X.509 (RFC 5280). The parts that matter for day-to-day operations are the validity window (a not-before and not-after date), the Subject Alternative Name list (the hostnames the certificate is valid for), the public key, and the chain of intermediate certificates that links your certificate back up to a trusted root.

Identity is the whole job of a certificate. It says nothing about how strong the encryption is once the connection is established - that is a separate concern covered by TLS configuration.

How certificate validation works

When your certificate arrives, the client runs a series of independent checks before it trusts the connection. Each one can fail on its own, and each maps directly to a way HTTPS breaks in the real world:

• Is it in date? The current time has to fall between the not-before and not-after dates. Past the expiry, the certificate is rejected outright.
• Does the name match? The hostname the client asked for has to appear in the certificate's Subject Alternative Name list, either exactly or through a single-label wildcard. A certificate for example.com does not cover shop.example.com unless that name (or *.example.com) is listed.
• Does the chain build to a trusted root? The client walks from your certificate through the intermediate certificates the server sent, up to a root it already trusts. If the chain does not reach a known root, the certificate is untrusted no matter how valid it is.
• Has it been revoked? A certificate can be in date, name-matched, and trusted, and still be pulled by its issuing CA before it expires - typically after a key compromise or mis-issuance. Clients that check revocation status reject a revoked certificate outright.

All of these have to pass independently. A certificate can be perfectly in date and chain to a trusted root, yet still be rejected - because it is for the wrong hostname, or because its issuer has revoked it. These are separate tests, and SecRift scores them separately for exactly that reason.

Why it matters

A broken certificate is one of the few security failures that stops traffic completely rather than quietly weakening it. When a certificate expires or fails validation, browsers do not degrade gracefully - they show a full-page interstitial warning that most visitors will not click through. The practical effect is an outage, and one that search crawlers and API clients hit just as hard as human visitors.

Beyond the hard failures, a few properties of the certificate itself carry real weight. The public key has to be strong enough that it cannot be factored or solved - RSA at 2048 bits or an elliptic curve at 224 bits and above. The signature has to use a hash function without practical collision attacks, which rules out MD5 and SHA-1. And modern browsers expect proof that the certificate was logged publicly through Certificate Transparency, so that mis-issued certificates for your domain can be detected after the fact.

Common mistakes

The single most common failure is a lapsed renewal. Certificates have a finite lifetime - publicly trusted ones are capped at around a year today, and that ceiling is scheduled to keep dropping. Any process that depends on someone remembering to renew will eventually miss, which is why automated renewal through ACME (Let's Encrypt or a managed CA) is the baseline expectation now rather than a nice-to-have.

The second is an incomplete chain. Your server has to send the intermediate certificate alongside your own, in the right order. Leave the intermediate out and you get the confusing bug where the site works in your browser - which had the intermediate cached - but fails for clients that do not fetch missing intermediates on their own. It looks intermittent, but it is a configuration gap every time.

The third is a hostname mismatch from a misrouted virtual host. When a server presents a default certificate for the wrong domain, the certificate itself is often completely valid - it just belongs to a different site sharing the same IP. This usually traces back to an SNI or virtual-host misconfiguration rather than anything wrong with the certificate.

How SecRift checks TLS certificates

SecRift connects to your domain's HTTPS endpoint on port 443, retrieves the certificate the server actually presents, and evaluates it through a native certificate enumeration. Nine scored findings come out of it:

• Validity - confirms the certificate is inside its validity window, warns when it expires within 30 days, and flags an expired or not-yet-valid certificate as critical. This carries the most weight, because expiry breaks HTTPS for everyone.
• Hostname match - checks the scanned hostname against the Subject Alternative Name list, following RFC 6125 wildcard rules (a single left-most label only). Common Name is deliberately ignored, matching how modern browsers behave.
• Chain trust - validates the chain against five independent trust stores (Mozilla, Apple, Android, Java, Windows), separating a fully trusted chain from one that only some clients accept and from a self-signed or private-CA certificate no store trusts.
• Revocation - actively queries the issuer's OCSP responder to confirm the certificate has not been revoked, independent of whether the chain builds. A revoked certificate - one its CA pulled after a key compromise or mis-issuance - is flagged even when its dates and chain are flawless. A responder that does not recognize the certificate yet is a low-severity advisory, and an unreachable responder or a certificate with no OCSP endpoint is reported as inconclusive rather than counted against you.
• Chain completeness - confirms the server sends at least one intermediate certificate in the correct order, catching the dropped-intermediate bug before your mobile users do.
• Key strength - checks the certificate's public key meets modern minimums: RSA at 2048 bits or more, or an elliptic curve of at least 224 bits. Modern curves like P-256 and Ed25519 pass cleanly.
• Signature algorithm - flags a leaf certificate signed with MD5 or SHA-1, and separately notes when an intermediate in the chain still uses SHA-1.
• OCSP stapling - rewards a trusted stapled revocation response, but does not penalize its absence. OCSP is being retired across the ecosystem, so a plain missing staple passes; only a stapled-but-untrusted response, or a Must-Staple certificate served without a staple, is flagged.
• Certificate Transparency - counts the embedded Signed Certificate Timestamps, since Chrome expects at least two for publicly trusted certificates.

This sits alongside SecRift's TLS configuration check, which scores protocol versions and cipher strength, and the TLS vulnerabilities probes, which test for specific implementation bugs like Heartbleed and ROBOT. A server can hold a flawless certificate while running a weak configuration, and the other way around - which is why they are three separate checks.

Run a free scan on any domain at secrift.com and see your TLS certificate posture in seconds.