Pemeriksa Sertifikat SSL/TLS

Why this needs a server

A browser can only open a TLS connection to a site it's actually navigating to — there's no JavaScript API for opening a raw TLS socket to an arbitrary host on demand. Reading what a different domain's server presents needs a real connection from somewhere else, so this tool's backend opens the handshake and reports back only connection metadata and public certificates, never anything private.

The same protections used by ProntoUso's other network tools apply here: every address the domain resolves to is checked before any connection is attempted, and private, loopback, and other internal ranges are refused outright. The port is limited to a fixed list rather than a free-form field, so this can't be used as a general-purpose port scanner against someone else's server.

What gets checked

The certificate chain exactly as the server sends it — every intermediate it offers, not filtered by any trust store first. A second, independent connection then checks that chain against a real trust store with host name verification turned on, which is what actually determines the 'Trusted by browsers' result.

Beyond the chain: which TLS versions the endpoint still accepts (1.0 through 1.3), the negotiated cipher and whether it provides forward secrecy, ALPN, a Strict-Transport-Security (HSTS) check, a CAA DNS record lookup, and whether plain HTTP on the same domain redirects to HTTPS.

Why multiple IP addresses

A domain behind a load balancer or a CDN often resolves to more than one public address, and it's entirely possible for one node to be running an old certificate or a looser TLS configuration than the rest. Up to three of a domain's public addresses are checked and graded independently, with a tab to switch between them, specifically to catch that kind of drift instead of only ever reporting whichever address happened to answer first.

Reading the grade

The letter grade is ProntoUso's own heuristic, not an official industry standard: it starts at 100 and subtracts points for each issue found (an expiring certificate, a weak key, a legacy protocol still enabled, missing HSTS, and so on). A handful of trust-critical problems — an expired or self-signed certificate, an untrusted chain, or a host name mismatch — force the grade down to an F outright, regardless of how well everything else scores, because none of those are things a browser would ever let a visitor past quietly.

'Trusted by browsers' is shown as its own separate yes/no result rather than folded only into the letter grade, since it's usually the single fact people actually came here to check.

What this doesn't check

Live revocation status (OCSP/CRL) isn't queried — checking that reliably needs a whole additional protocol this tool doesn't implement yet. Legacy TLS 1.0/1.1 support is reported best-effort: a hardened environment can refuse to even attempt a deprecated protocol locally, which is reported the same as the server itself rejecting it, so treat a 'not offered' result on those two versions specifically as inconclusive rather than a confirmed pass.