Identity & trust
Whether the certificate really belongs to this host and whether a browser can build a path to a trusted root.
- Certificate chain completeness
- Hostname / SAN match
- Self-signed detection
- Signature verification
Free · 11 checks · results in seconds
A padlock in the browser only means the certificate parsed. We test the chain, the expiry, the hostname match, the protocols and the ciphers — then say plainly what is fine and what is not.
Hostname to test
Coverage
Grouped by what breaks if they fail. Every result comes with the reason, not just a colour.
Whether the certificate really belongs to this host and whether a browser can build a path to a trusted root.
How long you have, and whether revocation status can actually be looked up by a client.
The part everyone forgets: what the server negotiates once the certificate is accepted.
Myths
“It shows a padlock”
Browsers cache intermediates from earlier visits. A missing intermediate looks fine on your laptop and fails on a customer’s phone or an API client.
“Auto-renewal is on”
A renewed certificate that never reaches the load balancer expires exactly on schedule. We check what the server actually serves, not what your CA issued.
“We got an A rating once”
A CDN change, a new ingress, a copied nginx block — protocols and ciphers move without anyone deciding to move them.
Questions
Want the whole perimeter, not one hostname? Run the attack surface scan next.
Scan my attack surface →No. A certificate can be perfectly valid while the server still accepts an obsolete protocol, offers weak cipher suites, fails to staple OCSP or serves an incomplete chain that breaks on older clients. The padlock only proves the browser could verify one certificate — it says nothing about the rest of the configuration.
Add your hostnames once and we watch every renewal, chain change and protocol downgrade — with alerts 30, 14 and 3 days out.