Loading Techie Utils…

SSL Certificate Checker

Grade a TLS endpoint and inspect the certificate it serves. Free, and checked from our server, so you see what the public internet sees.

About SSL Checker

This opens real TLS connections to the host and port you give it and reports both halves of the question: what the server is serving, and how good the configuration is. The certificate side is subject and issuer, validity window, subject alternative names, key and signature. The configuration side is a letter from A+ down to F, with every reason listed.

The grade follows the shape the published methodologies use. The certificate has to be trustworthy at all — trusted chain, right hostname, not expired — or the result is a T and nothing else is graded. After that the grade is held down by the oldest protocol version and the weakest cipher the server still agrees to, and the top grade is reserved for a host that also sets HSTS.

The evidence is gathered one connection at a time rather than inferred from a single handshake: each of TLS 1.0, 1.1, 1.2 and 1.3 is offered on its own to see whether it is accepted, a deliberately weak cipher list is offered to see whether it is refused, and a HEAD request reads the Strict-Transport-Security header.

The named attacks are listed separately, each with the evidence behind its verdict. Export suites, 3DES, RC4 and null encryption are each offered on their own — by suite number, in a hello written by hand, because Node's TLS library has none of them compiled in and could otherwise only report its own build options. A report can therefore say FREAK or Sweet32, and name the suite the server picked, rather than saying “a weak cipher”. The Diffie-Hellman group size decides Logjam; the protocol versions decide BEAST; the negotiated suite decides Lucky Thirteen and the padding oracles.

SSL 3.0, SSL 2.0 and TLS compression are asked about with a ClientHello built byte by byte on a plain socket, because Node's TLS stack will not speak the first two and is compiled without the third. Those are limits of the client, not facts about the server, and a checker has no business reporting the one as the other. The same hand-built hello is the control: it carries a TLS 1.2 offer too, so a refusal at SSL 3.0 can be told apart from bytes the server could not parse. Without that, “not vulnerable to POODLE” and “my hello was malformed” look identical, and only one of them is safe to print.

That hello also asks three questions the normal client never surfaces. Whether the heartbeat extension — the one Heartbleed lives in — is enabled at all; whether renegotiation is done the fixed way RFC 5746 describes; and whether session tickets are issued. Each is answered by the server echoing the extension or staying silent.

What is left unconfirmed is left unconfirmed. Heartbleed, Ticketbleed, ROBOT and the padding oracles all need a deliberately broken message to prove, which is an exploit attempt against a host you may not own, so those stop at “the precondition is present” and say what is missing. A tick nobody earned is worse than no tick: somebody reads it and stops looking.

Underneath, the whole chain the server sent is drawn as a collapsible tree — each certificate holding the one that issued it — with how long each has left and a marker at any link that does not join up.

Because it connects from the server rather than from your browser, it sees the public view of your host — the same one your users and monitoring get. Private, loopback and link-local addresses are rejected, so it cannot be pointed at an internal network.

Where it helps

  • One letter and a score out of 100, with every reason listed rather than left to be guessed at.
  • Tests each protocol version separately instead of reporting only what one handshake happened to negotiate.
  • Checks whether weak ciphers are actually accepted, which is the question a configuration file cannot answer.
  • Shows the served certificate in full — names, dates, key, signature and fingerprint.
  • Draws the served chain as a tree, so a missing intermediate is obvious.
  • Reads the HSTS header, which is the difference between A and A+.
  • Eighteen named attacks with the evidence behind each verdict — POODLE, DROWN, CRIME, BEAST, FREAK, Logjam, Sweet32, RC4, Heartbleed, ROBOT, Ticketbleed, Lucky Thirteen, Raccoon, BREACH and the rest.
  • Builds SSL 2.0, SSL 3.0 and the obsolete cipher suites by hand, so every one of them gets a real answer rather than a shrug about what the runtime can speak.

Limits

  • SSL 3.0 cannot be tested, because the runtime this uses cannot speak it; a server offering only SSL 3.0 will look unreachable.
  • Heartbleed, Ticketbleed, ROBOT and the padding oracles stop at their preconditions: confirming any of them needs a deliberately malformed message, and this will not send an exploit payload to a host on your behalf.
  • A check reports “not tested” only when a probe went unanswered — the verdicts are the server's, not a summary of what this runtime can speak.
  • Cipher order, session resumption, OCSP stapling and certificate transparency are not examined.
  • The grade reflects one moment and one address: a host behind a load balancer may answer differently from a different node.
  • It reads what is served, not what is configured — a proxy or CDN in front of your origin is what answers.
  • It cannot see private endpoints, and refuses addresses that are not publicly routable.

Frequently asked questions

Why is my grade capped at A rather than A+?

Almost always HSTS: the top grade needs a Strict-Transport-Security header with a max-age of at least 180 days. TLS 1.3 not being offered will also hold it at A.

What does a T mean?

The certificate itself is the problem — expired, for a different hostname, or not verifiable against the trust store. A browser would refuse the connection, so the ciphers behind it were not graded.

Does it actually test for Heartbleed?

It tests the precondition, not the bug. The hello offers the heartbeat extension and reports whether the server echoes it: no heartbeat means there is nothing to malform, which is a real answer. If it is enabled, confirming the bug means sending a heartbeat that lies about its own length — an exploit attempt against whatever host was typed into the box, which may not be yours — so it stops there and says so. Run a dedicated scanner against your own infrastructure for the rest.

How can it check SSL 3.0 if the runtime cannot speak it?

By writing the ClientHello as bytes on a plain TCP socket rather than asking the TLS library to do it. A ServerHello coming back means yes, an alert means no. The same builder sends a TLS 1.2 hello as a control, so a refusal at SSL 3.0 is known to be the server's answer rather than a hello of ours the server could not parse.

A weakness was found. Why did the grade not move?

Whether it moves depends which one. Export, 3DES, RC4 and null encryption are what the grade means by a weak cipher, so those are priced in it already and the list simply names which family it was — counting them twice would make the score disagree with its own reasons. A precondition finding such as ROBOT or Ticketbleed does not move the grade at all, because nothing has been confirmed.

Is this the same as the SSL Labs grade?

It follows the same shape — trust first, then the oldest protocol and weakest cipher — but it is a smaller test. Treat a difference as a prompt to look, not as a contradiction.

Does testing TLS 1.0 mean my server is insecure?

It means it will still answer a client that asks for it. Browsers stopped doing so in 2020, so the usual reason to keep it is a legacy device you can name — and if you cannot name one, turn it off.

The certificate here differs from the one I installed. Why?

Something in front of your origin is terminating TLS — a CDN, a load balancer or a reverse proxy. That is the certificate the public sees.

Related tools

More SSL & Certificates tools