🔐 Verificador de certificados SSL

About TLS Certificates

When your browser connects to an https:// address it does two things before a single byte of your data is sent: it agrees an encryption key with the server, and it checks that the server is who it claims to be. The second half is the job of the TLS certificate — often still called an SSL certificate, after the protocol TLS replaced.

This tool opens a genuine TLS connection to the host and port you give it, reads the certificate the server actually serves, and reports what it finds. It does not send any HTTP request, and it does not trust the certificate blindly — it deliberately inspects broken certificates so it can tell you precisely why they are broken.

What a certificate actually proves

A certificate binds a public key to a set of names. It proves that whoever holds the matching private key controls the names listed inside it, because a certificate authority (CA) checked that control before signing. That is all it proves. It says nothing about whether the site is honest, well run, or safe — only that you are talking to the operator of that domain rather than someone in the middle.

• Subject CN — the certificate's primary name. Modern clients ignore it in favour of the SAN list.
• Subject Alternative Names (SAN) — the authoritative list of hostnames and IP addresses the certificate covers. A wildcard such as *.example.com matches exactly one label, so it covers www.example.com but not a.b.example.com and not the bare example.com.
• Validity window — the not-before and not-after dates. Public certificates are now issued for short periods, typically 90 days or less.
• Public key — usually RSA 2,048-bit or an elliptic-curve key on P-256. EC keys are much smaller for equivalent strength.
• SHA-256 fingerprint — a unique digest of the whole certificate, handy for pinning or for confirming two servers serve the identical certificate.

The chain of trust

Your device ships with a store of root certificates from a few dozen CAs. Those roots are kept offline, so they almost never sign a website's certificate directly. Instead a root signs an intermediate, and the intermediate signs your certificate. Verification walks that path upwards:

The server must send every intermediate. It does not need to send the root: your device already has it, and a root arriving over the wire proves nothing. That is why a perfectly healthy site often shows a chain that stops one step short of the root.

Common failure modes and what they mean

• Expired — the not-after date has passed. Browsers refuse the connection outright with no easy way past it. This is the single most common cause of an unplanned outage, and it is entirely preventable with automated renewal.
• Not yet valid — the start date is in the future. Usually the server's clock is wrong rather than the certificate.
• Self-signed — the subject and issuer are the same, so no CA vouched for it. Fine on an internal service where you have distributed the certificate yourself, fatal on anything public.
• Hostname mismatch — the certificate is valid, but not for the name you asked for. Typically a bare domain missing from a wildcard certificate, a virtual host serving the wrong site, or a load balancer with stale configuration.
• Incomplete chain — the server sent its own certificate but omitted the intermediate. Desktop browsers often paper over this by fetching the missing certificate themselves, so the site looks fine to you while failing for mobile apps, API clients and curl. Always fix it rather than trusting your own browser.
• Untrusted root — the chain terminates in a CA your system does not trust, such as a corporate inspection proxy or a private internal CA.
• Weak signature or key — anything signed with SHA-1 or MD5, or using an RSA key below 2,048 bits, is rejected by current browsers.

Ports other than 443

Certificates are not only used for websites. Set the port field to check services that wrap TLS around another protocol from the first byte — IMAPS on 993, SMTPS on 465, POP3S on 995, LDAPS on 636, or an admin panel on 8443. Protocols that upgrade an existing plaintext connection with a STARTTLS command (SMTP on 587, IMAP on 143) cannot be checked this way and will report a handshake failure.

Renewal in practice

Treat 30 days remaining as the point to investigate and 7 days as an emergency. If you are renewing by hand, stop: use ACME automation such as Certbot, acme.sh or whatever your hosting platform provides, and monitor the expiry date so a silent renewal failure surfaces as an alert rather than an outage.