A certificate only matters at the moment a service presents it to a client. That is the only thing SSLBoard measures: it connects to each discovered endpoint and records what came back.
This is why the report and your certificate authority’s dashboard can disagree, and why the report is the one to believe.
What you might see
| Result | What it means and what to do |
|---|---|
| Expired certificate served | An endpoint is serving a certificate past its validity period. Replace it on every affected endpoint, then find out why renewal or deployment failed |
| Near expiration | A deployed certificate is running out. Confirm renewal reaches the endpoint before it expires. The score separates within 7 days from 8 to 15 days |
| Revoked certificate served | The endpoint is serving a revoked certificate. Replace it now and find out why it was revoked |
| Certificate or chain error | Validation failed: hostname mismatch, incomplete chain, or a trust problem. Read the error before picking a fix, they need different fixes |
| Dates or status unavailable | The evidence did not come back. This establishes neither validity nor a clean revocation status |
Renewal is not deployment
This is the single most common reason a finding survives a fix.
Issuing the replacement is the easy half. The certificate then has to reach every machine that terminates TLS for that name, and each of those has to load it. Any of these will keep the old certificate live:
- A load balancer pool where one node did not get the file.
- A CDN or reverse proxy holding its own copy, in front of an origin you just updated.
- A process that wrote the new file but never reloaded.
- An AAAA record pointing IPv6 traffic at a box nobody remembered.
So work from the affected IP and port in the finding, not from the hostname. If two addresses serve www.example.com and only one is expired, replacing the file on the healthy one changes nothing.
Issuers and names
Issuer distribution tells you which certificate authorities appear across your deployment. Lots of issuers is worth a look for operational consistency, but it is not a security finding.
Certificate names tell you what a certificate covers. They do not tell you those names are live, or that they belong to you. See adjacent domains for those relationships, and CAA for constraining who may issue for you in the first place.
Verify the replacement
Run a fresh retest and check that each affected endpoint now presents the certificate you intended, with the names and dates you expect.
Then check two neighbors, because a correct certificate can still be deployed badly: connection and certificate errors for chain problems, and OCSP stapling for a stale status response attached to a perfectly good certificate.