Skip to content

Security

Fixing SSL certificate without guessing

Fix certificate validity and public trust issues with named hosts, evidence, and a rescan—not folklore about padlocks.

· by Jonas Reed

Fixing SSL certificate without guessing

When an SSL certificate finding shows up, I want the mechanism, not a pep talk. SlaySlop's check "Reviews certificate validity and public trust signals." So the fix path starts from that observation: what leaf is presented, for which name, with what public trust story—then change the thing that produces that presentation.

Guessing looks like rotating random CDN toggles until a padlock appears on one laptop.

Outcome of a non-guessing fix

The scanned hosts present a certificate that is valid and publicly trusted. Evidence in the ticket matches the glossary claim. A rescan confirms the observation changed. Sibling issues (HSTS, TLS configuration) get their own tickets if they still fail.

Boundaries

Read-only scanning discovered the signal; fixing happens in your CA, CDN, or load balancer with normal change control. Permission required to test. Not a pentest. Not advice to weaken validation. SlaySlop does not push certs for you.

Do not "fix SSL" by enabling HSTS and calling it done. HSTS "Checks whether browsers are instructed to keep future requests on HTTPS." TLS configuration "Inspects the public transport configuration and supported connection behavior." Different observers.

Happy path fix loop

Loading diagram.

  1. Copy the hostname from the finding. Do not "fix production" while staring at staging.
  2. Confirm what the edge presents with a local observer you trust for cross-check.
  3. Reissue or renew with the correct SANs for every launch hostname that failed.
  4. Install the leaf and intermediates on the terminator that actually serves the host.
  5. Wait for propagation if multiple edges are involved.
  6. Rescan. Only then close the SSL certificate ticket.
  7. Open HSTS/TLS tickets separately if those rows still need work.
bash
# Permissioned cross-check after deploy
HOST=www.example.com
echo | openssl s_client -servername "$HOST" -connect "$HOST:443" 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
text
fix_ssl_ticket:
  host:
  observation: invalid|untrusted|name-mismatch|lifetime
  change: reissue|renew|chain-fix|edge-map
  deployed_at:
  rescan_url:
  ssl_certificate_after: pass|fail
  open_siblings: []

How the check observes the signal

At a lab-notebook level: the scan connects to the public host and reviews certificate validity and public trust signals on what was presented. I do not invent private OCSP heuristics beyond what the product surfaces. I treat the row as an observation of the public handshake artifact, then I change the artifact.

If product UI also shows remaining lifetime, I use that as calendar input, not as a substitute for naming the host in the ticket.

Pitfalls

Redeploying the old leaf to a new edge. Fixing only www while apex still fails. Enabling HSTS preload theater while the leaf is still wrong (painful combination). Declaring success from the CA email without a rescan. Mixing TLS cipher complaints into the SSL certificate ticket until nobody can find the leaf work.

Related next step

After the leaf passes, verify Strict Transport Security so browsers keep future requests on HTTPS. Soft links: SSL certificate, TLS configuration. Soft close: rescan in SlaySlop so the observation and the fix share one timeline.