Inspect SSL/TLS certificates
on any host or port.

Verify certificate validity, expiry dates, issuer chain, signature algorithms and STARTTLS-protected services. RFC-compliant inspection, instant results, no account required.

22 Monitoring nodes

15 Countries

< 2s Per check

$0 No account

Use STARTTLS only when checking the plaintext port of a protocol that upgrades to TLS in-band (e.g. SMTP on 25 / 587). Leave on "Direct TLS" for HTTPS, IMAPS, SMTPS and similar already-encrypted ports.

Host

Port

STARTTLS

Try:

Note: All checks are public. To keep your checks private, create a free account.

Global Network Diagnostics

Run a check to see your service from around the world.

Tested from 22 monitoring locations worldwide
Results in seconds, not minutes
Shareable result links for your team
No account or signup required

What is SSL/TLS?

Transport Layer Security (TLS) — the modern successor to the deprecated Secure Sockets Layer (SSL) — is the cryptographic protocol that secures the vast majority of internet traffic. When you load an https:// URL, send email between mail servers, or connect to a database from your application, TLS is what protects that connection from eavesdropping, tampering and impersonation.

A TLS connection begins with a handshake: the client and server negotiate a protocol version and cipher suite, the server presents an X.509 certificate signed by a trusted Certificate Authority, and ephemeral key material is exchanged. From that point on, all application data is encrypted with a symmetric key derived during the handshake.

The certificate is the public, verifiable identity of the server. It binds a public key to a domain name and is signed by a Certificate Authority that the client already trusts. Browsers, mail clients and most TLS libraries ship with a list of trusted root CAs and refuse to connect when the certificate does not chain to one of them.

"SSL" persists in everyday language — "SSL certificate", "SSL inspection" — but every modern deployment runs TLS 1.2 or TLS 1.3. SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 are all formally deprecated and should not be used.

A TLS certificate has a deadline. Miss it and your site goes dark — every modern browser refuses the connection, no negotiation. Watching certificate expiry is the cheapest insurance in modern web operations.

What an SSL/TLS Check Returns

An SSL/TLS check inspects the certificate the server presents during the handshake and surfaces every field that controls trust, validity and cryptographic strength. Each row below maps to a piece of information you should know about any TLS endpoint you operate.

Field	Description	Example
Subject	Hostname(s) the certificate is issued for.	CN=emercom.io
SANs	Subject Alternative Names — extra hostnames covered by the certificate.	emercom.io, www.emercom.io
Issuer	Certificate Authority that signed the certificate.	Let's Encrypt R10
Chain	Intermediate and root CA certificates presented by the server.	leaf → R10 → ISRG Root X1
Valid From / To	Notice and expiry dates of the certificate.	Mar 12 → Jun 10 2026
Serial	Unique certificate serial number.	04:5e:f3:9c:1a:…
Signature	Algorithm used to sign the certificate (e.g. SHA256-RSA).	SHA256-ECDSA
Public Key	Algorithm and key size (e.g. RSA 2048, ECDSA P-256).	ECDSA P-256 (256 bit)
Protocol / Cipher	Negotiated TLS version and cipher suite.	TLSv1.3 / AES-256-GCM

STARTTLS: Upgrading Plaintext to TLS

Several legacy protocols were designed before TLS existed and originally ran in plaintext. Rather than running two separate ports — one plaintext and one wrapped in TLS — these protocols use STARTTLS: a command that upgrades an existing plaintext connection to a TLS-protected one. The connection begins unencrypted, the client issues a STARTTLS command, the server responds, and the TLS handshake then runs over the same socket.

If you are checking a service that only listens on its plaintext port (for example, port 25 for SMTP between mail servers), the certificate is invisible to a regular TLS client. You need a tool that speaks the protocol enough to issue STARTTLS, then reads the certificate from the upgraded connection.

Protocol	Plaintext + STARTTLS	Direct TLS
SMTP	25 server-to-server · 587 submission	465 SMTPS
IMAP	143	993 IMAPS
POP3	110	995 POP3S
FTP	21 FTPS-explicit	990 FTPS-implicit
LDAP	389	636 LDAPS
XMPP	5222 c2s · 5269 s2s	5223 legacy

When to enable STARTTLS

Pick a STARTTLS protocol when the port you are checking is the plaintext port for that service. Leave the dropdown on Direct TLS if you are checking https:// on 443, a direct-TLS port like 993 / 465 / 636, or any port that begins the connection encrypted.

Picking the wrong mode is the most common reason a check fails on a non-HTTPS port. SMTP server-to-server traffic almost always needs STARTTLS (SMTP) — port 25 will not present a certificate without it.

Reading a Certificate

A TLS certificate carries the cryptographic proof that the server you are talking to is the one named in the certificate. Each field tells you something about how it was issued, what it covers and how long it remains valid.

Identity Fields

Subject Common Name (CN) historically held the hostname the certificate was issued for. Modern clients (every current browser) ignore the CN entirely and only honour the Subject Alternative Name extension, but you will still see it populated for backward compatibility.

Subject Alternative Names (SANs) are the authoritative list of hostnames the certificate is valid for. A single certificate can cover many names — for example, example.com, www.example.com and *.example.com. If the hostname you connected with is not in the SAN list, the connection will fail with a name-mismatch error regardless of how the certificate is otherwise valid.

Issuer identifies the Certificate Authority that signed this certificate. For publicly trusted certificates this will be a well-known CA — Let's Encrypt, DigiCert, Sectigo, Google Trust Services, ZeroSSL and so on. Self-signed and private-CA certificates show whatever organization issued them, but clients will reject them unless that CA has been explicitly trusted.

Validity & Cryptography

Not Before / Not After define the validity window. A certificate is invalid before its start date and after its expiry. Public CAs cap maximum lifetimes — Let's Encrypt issues 90-day certificates, and the CA/Browser Forum reduced the maximum lifetime for publicly trusted certificates to 398 days in 2020 with further reductions planned.

Signature Algorithm is the algorithm the issuing CA used to sign this certificate (commonly SHA256-RSA or SHA256-ECDSA). SHA-1 has been deprecated since 2017 and any certificate still using it will be rejected by modern clients.

Public Key describes the key embedded in the certificate. RSA 2048-bit and ECDSA P-256 are the modern standards; RSA 1024 is no longer accepted, and RSA 4096 or ECDSA P-384 are common for higher-security deployments.

Serial Number uniquely identifies this certificate within its issuing CA. It is the value you supply when revoking a certificate or looking it up in CT logs.

The Certificate Chain

Servers do not present just a single certificate — they present a chain. The leaf certificate (the one issued for your domain) is signed by an intermediate CA, which is in turn signed by a root CA. The client trusts the root, follows the chain of signatures down to the leaf, and rejects the connection if any link is missing, expired or revoked.

A correctly configured server sends the leaf and all intermediate certificates in its chain. The root is not sent — the client already has it in its trust store. The single most common cause of TLS configuration failures is a server that forgot to include an intermediate, which can produce errors like incomplete chain or unable to verify the first certificate depending on the client.

A Real Certificate, Up Close

The fields in the section above are easier to grasp when you can see them on the wire. Below is what openssl s_client prints when you connect to emercom.io:443 — every meaningful piece of a TLS handshake distilled to its smallest representation.

On the wire — what openssl s_client -connect emercom.io:443 -servername emercom.io prints

$ openssl s_client -connect emercom.io:443 -servername emercom.io
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
depth=1 C = US, O = Let's Encrypt, CN = R10
depth=0 CN = emercom.io
verify return:1
---
Certificate chain
 0 s:CN = emercom.io
   i:C = US, O = Let's Encrypt, CN = R10
 1 s:C = US, O = Let's Encrypt, CN = R10
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
subject=CN = emercom.io
issuer=C = US, O = Let's Encrypt, CN = R10
notBefore=Mar 12 08:14:33 2026 GMT
notAfter=Jun 10 08:14:32 2026 GMT
---
SSL handshake has read 4521 bytes and written 426 bytes
Verification: OK
---
Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384
Server public key is 256 bit ECDSA

Identity — subject / SAN (the queried thing) Issuer / negotiated crypto — trust chain & protocol Validity window — drives expiry monitoring

Read the chain top-down. depth=2 is the root (ISRG Root X1) — the client already has this in its trust store, so the server didn't send it. depth=1 is the intermediate (Let's Encrypt R10) — the server DID send it; without it, the client can't connect the leaf to the trusted root. depth=0 is the leaf, the cert actually issued for emercom.io. Every level says verify return:1, meaning each link checked out cryptographically.

The two dates are what drives expiry monitoring. Let's Encrypt issues 90-day certs and clients refuse the connection the instant notAfter passes. The window between notBefore and notAfter is the only time this cert is valid; outside it, the connection fails with certificate has expired or certificate not yet valid.

The bottom block is the negotiated connection — protocol version (TLS 1.3) and cipher suite (AES-256-GCM with SHA-384). These are not certificate properties; they are what the client and server picked at handshake time. A weak choice here (TLS 1.0, or a cipher with a known vulnerability) means the server's TLS config needs hardening even if the cert itself is fine.

Common TLS Failure Modes

When a TLS connection fails, the client typically returns one of a small set of canonical error messages. Each one points at a different category of problem.

Symptom	Likely cause
certificate has expired	The Not After date has passed. Renew the certificate.
hostname mismatch	The hostname you connected with is not in the certificate's SANs.
unable to verify the first certificate	The server is not sending intermediate certificates. Re-bundle the chain.
self signed certificate	The certificate is not signed by a trusted CA — common in dev/internal services.
certificate not yet valid	The Not Before date is in the future, or the system clock is wrong.
weak signature algorithm	Certificate is signed with SHA-1 or another deprecated algorithm.
handshake failure	No mutually supported protocol or cipher — server may be on TLS 1.0 / 1.1 only.

Why expiry monitoring matters

An expired certificate takes down a service exactly as effectively as the server crashing — every modern client refuses the connection. Outages from expired certificates have hit Microsoft Teams, Spotify, Cisco, the US federal court system and countless smaller services, often during weekends or holidays when the on-call engineer who set up the certificate is unreachable.

Continuous monitoring is the only reliable defence. Setting calendar reminders for renewal works until somebody changes jobs, somebody adds a new service, or an automated renewal silently fails. Active monitoring alerts you weeks in advance and again when something is wrong, regardless of who is on the team.

Why Check SSL/TLS From Multiple Locations?

Unlike a WHOIS lookup, an SSL/TLS handshake speaks to whichever physical server happens to terminate the connection — and that server is rarely the same across regions. CDNs, Anycast endpoints and regional load balancers each carry their own copy of the certificate, and any of them can drift out of sync with the others. Five inconsistencies that single-location inspection routinely misses:

CDN edge cert drift. During a rolling renewal, some edges serve the new cert while others still serve the old one. A single-location check shows whichever edge it happens to hit; the lagging edges go undetected until their cert actually expires.
GeoDNS-routed cert serving. Some setups deploy region-specific certs — a separate cert per IDN, or a different SAN list per continent. Multi-location lookup confirms each region receives the right one, end-to-end.
Anycast routing oddities. Same IP, but a misconfigured anycast announcement can route some regions to an entirely different box — a stale staging server, a plaintext HTTP-only host, or a partner's misrouted address. Multi-location handshakes reveal the divergence.
Network-path TLS interception. Corporate proxies, school networks and some national firewalls inject their own CA into client trust stores and re-sign connections in transit. From outside that network, the cert looks normal; from inside, it's swapped. Multi-location checks reveal which regions see the genuine cert.
Cert rotation visibility. Mid-renewal, you want to know which edges have picked up the new cert and which are still serving the one expiring tomorrow. 22 locations give you a complete rollout map in seconds instead of guessing.

Emercom inspects the certificate from all 22 monitoring nodes simultaneously, surfacing any region where the served cert differs from the rest — by SANs, expiry, issuer or chain composition.

Common Uses for SSL/TLS Check

An SSL/TLS check is one of those tools that everyone needs eventually. Four of the most common workflows it lives inside:

Pre-Deploy Verification

Before pointing DNS at new infrastructure, confirm the cert is correctly served: right SANs, valid window, complete chain, modern protocol. Catches the misconfiguration before users hit it — almost always cheaper than rolling back after an outage.

Expiry Monitoring

The single most important SSL workflow. Track Not After across every endpoint, alert weeks in advance, and verify automated renewals actually completed. Expired certificates have caused multi-hour outages at Microsoft, Spotify and the US federal court system — preventable with one cron job.

Compliance Audit

PCI-DSS, HIPAA, SOC 2 and similar frameworks require TLS 1.2+ with modern ciphers, no SHA-1 signatures, no weak RSA keys. A scheduled inspection across every endpoint produces auditable evidence — and surfaces drift the day it appears, not the day before the audit.

Cross-Region Consistency

For CDNs, regional load balancers and Anycast endpoints, confirm every node serves the same cert with the same validity window. Catches drift introduced by partial deployments or stale edges — the classic "works for me, broken for half of Europe" failure mode.

SSL/TLS Myths That Won't Die

TLS has been the dominant transport-security protocol for over two decades, and a lot of folk knowledge about it predates the modern best practices. Six assumptions worth retiring:

"SSL is secure, TLS is just a rename."

Reality: SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 are all formally deprecated. SSL as an actual wire protocol no longer exists. The word survives in marketing copy and product names ("SSL certificate", "SSL inspection") but every modern connection runs TLS 1.2 or 1.3.

"A green padlock means the site is safe."

Reality: A padlock means the connection is encrypted to the named server. It says nothing about whether the site is trustworthy. Phishing sites use TLS too — Let's Encrypt and similar free CAs will issue a cert to anyone who controls the domain. The padlock vouches for the transport, not the content.

"Longer-lived certificates are better."

Reality: The industry has aggressively shortened max lifetimes — currently 398 days, dropping to 47 days in 2029. Shorter lifetimes force automation and limit the damage window if a private key leaks. The era of "renew once every two years" is over; the trend is monthly.

"Self-signed certs are insecure."

Reality: A self-signed cert provides the same encryption as a CA-signed one. The difference is trust, not crypto — clients don't recognize the signer. Self-signed (or private-CA-signed) certs are entirely appropriate for internal services where you control both ends; mTLS systems and service meshes routinely use them.

"TLS 1.3 is twice as fast as TLS 1.2."

Reality: TLS 1.3 has a 1-RTT handshake vs TLS 1.2's 2-RTT, plus 0-RTT resumption — meaningful improvements. But the absolute savings on a cold connection are typically 50-100 ms, dwarfed by TCP setup, DNS, and HTTP transfer. Real-world page-load impact is small unless RTT is high.

"ECDSA is always better than RSA."

Reality: ECDSA P-256 is smaller, faster, and the modern recommendation — but compatibility matters. RSA 2048 is supported by everything; ECDSA requires the client to understand elliptic curves. For public web servers in 2026, the right answer is often "serve both" via multi-cert configurations and let the client pick.

Frequently Asked Questions

Quick answers to the most common questions about SSL/TLS certificates and the inspection tool.

What is the difference between SSL and TLS?

SSL and TLS serve the same role — encrypting connections between clients and servers — but TLS is the modern successor. SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 are all formally deprecated. Every modern connection runs TLS 1.2 or 1.3. The word "SSL" persists in product names and marketing copy ("SSL certificate"), but the actual wire protocol in use today is always TLS.

How often should I renew my certificate?

As often as your CA allows, and you should automate it. Let's Encrypt issues 90-day certificates and recommends renewal at 60 days. Commercial CAs can issue up to 398-day certs today, dropping to 47 days in 2029. The trend across the industry is shorter lifetimes; manual calendar reminders are no longer a viable renewal strategy.

What is STARTTLS, and when do I need it?

STARTTLS is a command that upgrades an existing plaintext connection to TLS in-band. You need it when checking the plaintext port of a protocol that supports both modes — SMTP on 25 or 587, IMAP on 143, POP3 on 110, FTP on 21, LDAP on 389, XMPP on 5222/5269. Pick the protocol from the STARTTLS dropdown when checking those ports; leave it on "Direct TLS" for HTTPS, IMAPS, SMTPS or any port that begins encrypted.

Why does my cert work in one browser but not another?

Three common reasons. First, different trust stores — older devices may lack the new root CA in their preloaded list. Second, different chain validation strictness — some clients refuse incomplete chains where others tolerate them. Third, different supported TLS versions — older systems may not speak TLS 1.3 or modern cipher suites. Identify which client is failing first, then check chain completeness and protocol negotiation.

What is a Subject Alternative Name (SAN)?

The authoritative list of hostnames a certificate is valid for. Modern clients only check SANs — the legacy Common Name field is ignored. If you connect to https://api.example.com but the cert only has example.com in its SANs, the connection fails with a hostname-mismatch error regardless of how the certificate is otherwise valid. Always include every hostname in the SAN list when issuing a cert.

Is RSA 2048 still safe?

Yes, for now. NIST and the CA/Browser Forum still consider RSA 2048 adequate for general-purpose web certificates. ECDSA P-256 is the modern recommendation — smaller, faster, equivalent or better security. For higher-assurance deployments, RSA 3072 / 4096 or ECDSA P-384 are common. Avoid RSA 1024, which has been deprecated for over a decade.

Related Tools

More free network diagnostics, all running from the same 22-location footprint.