Published rules

Twelve rules, R1 to R12.

Every result on a reading comes from one of these rules, with its number. Levels: OK Note Check Fix. The trust store in use right now: 120 roots in the server's CA bundle (Mozilla-derived), dated 2026-10-21.

RuleWhat it checksApplies toExactly howResults

R01 Name Server checks, and file reads with a name The name must be in the certificate's Subject Alternative Name list. A wildcard such as *.example.com stands for exactly one left-most label: it covers www.example.com, not example.com and not a.b.example.com. When the list exists, the Common Name is ignored, as browsers do (since 2017). No list at all = Fix. OK or Fix

R02 Dates The site's certificate Not valid yet, or expired = Fix. Fewer than 14 days left = Check. This is a reading of today's date, not a watch: nothing is checked again unless you ask. OK, Check or Fix

R03 Order What the server sends Each certificate must be signed by the one after it (the signature is verified with that certificate's public key, not guessed from names). The site's own certificate goes first. Out of order = Fix for a server; for pasted files, a Note (the files we give back are in order). OK, Note or Fix

R04 Missing intermediate Every chain If the chain cannot reach a trusted root with what was sent, the certificate's own "CA Issuers" address is fetched (at most twice, public addresses only, 64 KB) and the result is accepted only if its signature checks. Needed and fetched = Fix (it is put into fullchain.pem). Not found = Fix. OK or Fix

R05 Root sent What the server sends Clients already hold their roots, so a self-signed root sent by the server is never used; it only adds bytes. A cross-signed copy of a root is different: only very old devices that lack the root use it. Note only; the files we give back leave both out, and say when to add a cross-signed copy back. Note

R06 Stray certificate What the server sends A certificate that signs nothing in the chain. Some clients stop at it. Fix for a server, Note for pasted files (left out of the files). Note or Fix

R07 Trust Complete chains The chain must end at a root in the trust store: the Mozilla-derived CA bundle on our server (its date is shown on every reading). Self-signed certificate or a private root = Check: fine for a router or a company network that installs its own root, not for a public site. OK or Check

R08 Intermediate dates Intermediates An intermediate that has expired, or is not valid yet, breaks the chain even when the site's certificate is fine. Fix. Fix

R09 Key Certificate and intermediates RSA under 2048 bits, or DSA = Fix. EC keys must be on P-256, P-384 or P-521, else Check. OK, Check or Fix

R10 Signature Certificate and intermediates SHA-1 or MD5 signatures = Fix. Browsers stopped accepting SHA-1 certificate signatures in 2017. OK or Fix

R11 Lifetime Publicly trusted certificates Under the CA/Browser Forum Baseline Requirements, a public certificate may be valid for at most 398 days if issued from 2020-09-01, 200 days from 2026-03-15, 100 days from 2027-03-15 and 47 days from 2029-03-15 (ballot SC-081). Longer than allowed for its issue date = Note. Note

R12 Request and certificate File reads with a CSR Paste the certificate request with the certificate. Same public key = OK: the certificate belongs with the private key that made the request. Different = Fix (the "key values mismatch" error). OK or Fix

Not checked here: cipher suites, protocol versions offered, revocation (OCSP/CRL), Certificate Transparency logs, HSTS or anything else about the website. The TLS version on a reading is the one the handshake happened to use, shown for information.