Checking a Certificate Before It Embarrasses You: Fields, Dates and Names

Certificate warnings are among the most visible failures a site can have, because they appear to visitors before any content does, and they teach visitors to distrust the site. Most warnings trace back to a small number of checkable facts: the certificate expired, the certificate names a different site, the certificate was issued by an authority the visitor does not trust, or the certificate is not permitted for the use the server is making of it. All of these facts are visible in the certificate itself, which means they can be checked before deployment rather than discovered by visitors afterwards. The SSL Certificate Checker reads certificate text you paste in and reports those facts in plain form, so a renewal, a reissue, or a migration can be verified in a minute.

A certificate is a structured document, not a magic token. Its subject field names the entity it was issued for, and for a website that means the domain names it covers, listed in the subject alternative names field. Its issuer field names the certificate authority that signed it. Its validity field gives two dates: not valid before, and not valid after, and the certificate is only usable between them. Its public key and signature algorithm describe the cryptography, and its extensions describe permitted uses, such as server authentication, and constraints, such as whether it may act as an authority. A checker extracts these fields and presents them so that a human can compare them against what was intended: the right names, the right issuer, the right dates, and the right purposes.

How it works

Checking a pasted certificate starts with parsing the PEM text, the familiar block that begins with a header line and contains base64 data. The checker decodes that text and lists the fields in order. The first checks are the dates: is the certificate currently within its validity period, how many days remain before expiry, and does the not-valid-before date lie in the future, which would mean the certificate is not yet usable? Expiry is the single most common certificate failure, and it is almost always a diary problem rather than a technical one, because a certificate that expires on a weekend or a holiday will wait for nobody.

The next checks concern names. The checker lists every subject alternative name and compares them with the names the site actually serves. A certificate for www.example.com does not cover example.com unless example.com is also listed, and a wildcard such as *.example.com covers one level of subdomain, such as shop.example.com, but not two levels, such as deep.shop.example.com, and not the bare domain itself. Name mismatches are the second most common failure, and they usually appear after a site adds a new subdomain or moves to a bare domain without updating the certificate. The checker also reports the issuer, the signature algorithm, and the key size, so that weak or outdated choices, such as a short key or an obsolete signature algorithm, can be spotted before they become a compliance problem.

Worked example

Consider a sample certificate with clearly labelled sample values. The subject alternative names are www.example.com and example.com. The issuer is Example Certificate Authority. The validity runs from 1 February 2026 to 1 February 2027. The public key is 2048 bits, and the signature algorithm is a modern SHA-256 based algorithm. The extended key usage includes server authentication. Checking this certificate against a site that serves both www.example.com and example.com gives a clean result on every field: both names are covered, the dates span the current date of 1 July 2026 with about seven months remaining, the issuer is a recognised authority, and the usage permits server authentication.

Now change one fact: the site adds a new subdomain, shop.example.com, but the certificate is not updated. A visitor to shop.example.com now receives a certificate whose names do not include shop.example.com, and the browser warns that the certificate is not valid for that name. The site itself is unchanged, the server is unchanged, and the certificate is still in date, yet visitors see a security warning, because the certificate's name list and the site's real names have diverged. The fix is to reissue the certificate with shop.example.com added to the names, and the lesson is to treat a new subdomain as a certificate event, not just a DNS event. Similarly, if the same certificate were checked on 2 February 2027, it would fail on dates alone, even though nothing else had changed, which is why expiry monitoring belongs in a calendar, not in memory.

Mistakes to avoid

The most common mistake is letting a certificate expire, which is preventable with a diary entry set weeks before expiry, not on the day itself, because reissue and deployment take time and can fail. A second mistake is covering the wrong names, particularly forgetting the bare domain when only the www name is listed, or assuming a wildcard covers more levels than it does. List every name the site serves, and check the list after every subdomain change. A third mistake is deploying a certificate for one server on another server, or deploying a renewed certificate while the server still serves the old one, which produces a mismatch between what was checked and what visitors receive. Always re-check the served certificate after deployment, not just the file that was issued.

A fourth mistake is ignoring weak cryptography until it becomes urgent. Short keys and obsolete signature algorithms are flagged by checkers long before browsers reject them, and upgrading during a planned renewal is far cheaper than upgrading under a browser deadline. Finally, the handling rule: a certificate checker needs the public certificate text only. Never paste a private key, a certificate signing request containing sensitive details you do not intend to publish, or any password into a checker. A private key that has been pasted into any external tool should be treated as compromised, and the corresponding certificate should be replaced.

Putting it into practice

Add certificate checking to two routines: deployment, where the pasted certificate is checked before the server switch, and monitoring, where expiry dates are diarised with a lead time of at least thirty days. Keep a short inventory of which certificate covers which names on which servers, so a subdomain addition or a server migration immediately raises the question of whether the certificate still fits. Neighbouring checks include the HTTP Headers Checker for confirming that a site also sends sound security headers, and the DNS Lookup for confirming that names resolve to the intended servers. For background reading, the related guide explains the header side of site security, which complements the certificate side covered here.

Key points

• A certificate's dates, names, issuer, and permitted uses are all visible in the certificate itself
• Expiry and name mismatch are the two most common causes of browser warnings
• A wildcard covers one subdomain level only, and does not cover the bare domain
• Check pasted certificate text only, and never paste a private key into any checker