SSL SAN Checker

List every name a certificate protects. Enter a domain and this tool reads the live certificate and shows all of its Subject Alternative Names (SANs) — the apex domain, www, every subdomain, and any wildcards. It also confirms whether the host you entered is actually covered, so you can verify a multi-domain or wildcard certificate before a hostname mismatch error surprises your visitors.

How to use the SSL SAN Checker

Enter a domain and press List SAN names. The tool connects to the server, reads its certificate, and lists every Subject Alternative Name on it. At the top you also get:

• A count of how many names the certificate covers.
• A clear yes/no on whether the exact host you entered is included — the thing that determines whether browsers accept the certificate for that address.

Use the Copy all names button to grab the full list for documentation, a ticket, or to compare against the hostnames you actually serve. Wildcard entries appear as *.example.com, which match any single label under that domain.

What Subject Alternative Names (SANs) are

A Subject Alternative Name is an entry in the certificate that lists a hostname (or sometimes an IP address) the certificate is valid for. Modern browsers rely entirely on the SAN list to decide whether a certificate matches the site you are visiting — the old Common Name field is ignored for this purpose. So the SANs are the definitive list of names a certificate protects.

That makes SANs central to how real-world certificates are issued:

• Apex + www — almost every certificate lists both example.com and www.example.com, because they are different hostnames and each must be present to avoid a mismatch error.
• Multi-domain (SAN/UCC) certificates — a single certificate can cover many unrelated domains by listing them all as SANs, which is common behind CDNs and shared load balancers.
• Wildcards — an entry like *.example.com matches any single subdomain label (app.example.com, api.example.com) but not the apex and not deeper labels like a.b.example.com. A certificate often pairs *.example.com with example.com to cover both.

If a visitor reaches your site on a hostname that is not in the SAN list, their browser shows a hard "this certificate is not valid for this domain" error. Checking the SAN list is therefore the way to confirm a certificate covers every hostname you actually serve — before you discover a gap from an error report. Because this tool reads the certificate the server presents live, the list it shows is exactly what browsers will check against.

Common use cases

• Verifying a multi-domain certificate — confirm every domain you intended to include actually made it onto the certificate.
• Checking wildcard coverage — see whether *.example.com is present and remember it does not cover the apex, which needs its own entry.
• Diagnosing a hostname mismatch — when a specific subdomain throws a certificate error, check whether that exact name is in the SAN list.
• Pre-launch QA — before adding a new subdomain to production, confirm the live certificate already covers it (or reissue first).
• Inventory and documentation — copy the full name list for your asset records or a security review.

SAN, wildcard and Common Name: the differences

• Common Name (CN) — a single legacy name field. Browsers no longer use it for hostname validation, so a certificate must rely on SANs even if the CN looks right.
• SAN list — the modern, authoritative list of covered hostnames. Each name you serve must appear here.
• Wildcard — *.example.com covers exactly one level of subdomain. It does not cover the bare example.com or multi-level names like x.y.example.com. Pair it with an apex entry for full coverage.
• Multi-domain (UCC) — many distinct domains listed as SANs on one certificate; efficient but means renewing one certificate affects all of them.