Common SSL certificate mistakes that still ship

I still reach for curl and openssl first. That habit is fine for one host. It does not stop the shipping mistakes I keep seeing: wrong name on the leaf, renewal that never fired, or a CDN edge that still serves yesterday's certificate while the homepage looks fine on my laptop.

SlaySlop's SSL certificate check "Reviews certificate validity and public trust signals." The mistakes below are how teams still fail that public-surface review under calm uptime.

Outcome if you fix these early

Fewer "your connection is not private" screenshots in Slack. Tickets that name the hostname. A renewal owner written down before launch week. Less synonym cycling into a vague "TLS ticket" that nobody can search later.

Boundaries

Public read-only scanning. Permission required. Not a pentest. SSL certificate is not TLS configuration ("Inspects the public transport configuration and supported connection behavior."). HSTS is a sibling about future HTTPS instructions ("Checks whether browsers are instructed to keep future requests on HTTPS."), not leaf validity. CSP and frame protection do not prove trust. SlaySlop will not issue or renew certificates.

Happy path: the mistakes I still see

Mistake 1: Staging names on production leaves

The certificate was issued for staging.example.com, an old brand hostname, or a load-balancer nickname. Your browser accepted a temporary exception once, so you stopped looking. Outsiders did not. Neither did crawlers that hit a warning.

Mistake 2: Apex and www diverge

www renewed. Apex did not. Or the reverse. Clients type both. Ads sometimes use both. I check both before I say HTTPS is done.

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName
echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Mistake 3: "HTTPS works" with a thin lifetime left

Validity today is not a plan. Product language around remaining days exists because calendars beat optimism. Put a reminder or ongoing monitoring next to the finding. I have watched teams ship on a cert with single-digit days left because QA ran last month.

Mistake 4: Collapsing SSL certificate into folklore grades

Lab-oriented TLS views are adjacent product concepts. Do not invent grades inside the SSL certificate glossary claim. Stick to validity and public trust signals for this check. Open TLS configuration when handshake behavior is the real question.

mistake_log:
  host:
  symptom: name-mismatch|expired|untrusted|host-gap|lifetime
  evidence: openssl|browser|slayslop
  fix_owner:
  rescan_after:

Pitfalls in interpreting the result

Assuming the CDN UI equals what every edge serves right now. Ignoring chain issues because the leaf dates look fine in isolation. Padding tickets with invented severity math or prices. Treating a clean SSL row as proof HSTS or CSP shipped.

I also see people verify from a corporate network that MITM-inspects TLS with a corporate root. That is not the public trust signal outsiders see. Use a clean path when you can.

What I do after a fix

Renew or reissue, wait for edge propagation, then rescan. Paste the host and the new dates into the ticket. Only then open HSTS if the original complaint was "people still end up on HTTP somehow."

Related next step

Fix the leaf, rescan, then read Strict Transport Security so HTTPS stays the default for returning browsers. Soft link: SSL certificate. Soft close: a permissioned SlaySlop report beats a folder of openssl screenshots when the client asks what changed.