SSL Certificate Checker
Is this site’s certificate valid, trusted and set up right?
Checked from our server in Newark, US · the way a browser connects
Press Check to map spotify.com
- Certificate
- Missing
- TLS · HSTS · CAA · CT
- Name or server
- SENTby the server
- STOREin our trust store
The handshake New
Findings
Counted, never scoredThe trust graph, as a list
Every star above is a row here, and every row is a star. Hover one to light the other.
Findings New
What stands out, counted by state. Never a grade.
The chain New
From the site’s certificate up to a root our trust store holds. The server must send everything except the root.
Names and servers
The names the certificate covers, and every address the name points to, each asked from Newark, US.
Protocols New
One handshake per TLS version from our server. 1.0 and 1.1 are retired and should be off.
HSTS, the redirect, CAA and CT New
The extras that keep HTTPS honest. The revocation address is shown, never fetched.
Fingerprints and serial
To compare with the certificate on your server.
Recent checks
Kept in this browser only, with the days left at the time.
Kept in this browser only · nothing is sentEmail reminders: for registered users, coming soon
What the SSL checker shows
When you open a site over HTTPS, its server proves who it is with a certificate. This tool connects to a host from our server in Newark, US, the way a browser would, and shows the certificate it sends, who issued it, which names it covers and when it expires.
It also follows the chain up to a trusted root, tries each TLS version, and checks the extras that keep HTTPS honest: the HSTS header, the redirect from http://, the domain’s CAA record and the Certificate Transparency stamps inside the certificate.
How to use it
- Enter a domain or host name, like
example.com. A full URL works too. - Pick a port if it isn’t a website on 443: 8443, or 465, 993 or 995 for mail.
- Press Check. Run it again after renewing to confirm the new certificate is in place.
Understanding the results
The chain runs from the site’s own certificate through one or more intermediates to a root. We judge trust against our server’s store of root certificates, which isn’t every device’s. Servers must send the intermediates: when one is missing, some browsers and apps can’t build the chain and show an error.
Days left counts down to expiry. Many certificates now last 90 days or less (Let’s Encrypt’s do), and most setups renew them automatically with about a third of their life to go.
TLS 1.0 and 1.1 are retired and should be off; a version our server can’t offer itself is marked untested. HSTS tells browsers to use HTTPS only, and the redirect sends http:// visitors to the secure site; we ask for both on ports 443 and 8443. CAA names the certificate authorities allowed to issue for the domain. Certificate Transparency stamps show the certificate was logged publicly: we list each log by its ID and time, and don’t ask the logs themselves.
SSL checker questions
My browser says the site is secure. Why does this say the chain is incomplete?
Browsers often fill in a missing intermediate from their cache. Other apps and older devices don’t, so the server should send the full chain.
When should I renew?
Before it expires, ideally with 30 days to spare. Let’s Encrypt clients renew on their own; check again afterwards.
Can it check mail servers?
Yes, on ports 465, 993 and 995, which start with TLS. Ports that switch to TLS later with STARTTLS (25, 587, 143 and 110) aren’t checked.
Does it check every server?
It asks up to six addresses the name points to, so you can spot one server that still has an old certificate. Addresses our server can’t reach are marked.
Is the certificate revoked?
We show where its issuer publishes revocations (a CRL or OCSP address) but don’t fetch the list.
Are checks stored?
Your recent checks are listed in this browser only. Our server keeps each result for 30 days so you can make a PDF report, which carries a reference anyone can verify.