SAN Extractor

Extract all Subject Alternative Names from an SSL certificate

About SAN Extractor

The Subject Alternative Name (SAN) field in an SSL certificate lists all domains and subdomains that the certificate secures. Our SAN Extractor connects to any HTTPS server, retrieves the certificate, and parses the SAN extension to display every DNS name, wildcard entry, and unique apex domain. This is essential for understanding certificate coverage, auditing multi-domain certificates, and verifying that all your domains are properly protected.

How to Use

Enter the domain name (e.g., example.com) of the server whose certificate you want to inspect.
Click "Extract SANs" to fetch and parse the certificate from the server.
Review the extracted SANs — the tool shows total count, DNS names, wildcard entries, and unique apex domains.
Use the certificate info section to verify the issuer, validity period, and serial number.

Use Cases

•Audit multi-domain and wildcard certificates before renewal
•Verify that all required subdomains are covered by a certificate
•Compare SAN lists across different environments (staging vs production)
•Identify unused or unexpected domains in certificate SAN entries

Frequently Asked Questions

A Subject Alternative Name (SAN) is an extension to an SSL certificate that allows it to secure multiple domains and subdomains under a single certificate. SANs replaced the older Common Name (CN) field as the primary way to specify certificate domains.

There is no hard limit, but most Certificate Authorities (CAs) impose practical limits. Standard single-domain certificates include 1 SAN, multi-domain certificates can include 3 to 100+ SANs, and wildcard certificates cover unlimited subdomains under one apex domain.

A regular SAN (e.g., www.example.com) secures only that exact domain. A wildcard SAN (e.g., *.example.com) secures all subdomains at one level, like mail.example.com, blog.example.com, and api.example.com, but not example.com itself.

Because it stopped being used for validation. Certificate authorities were issuing certificates containing the intended names in the common name in ways that made abuse easy, so the industry moved to requiring names in the subject alternative name and having clients ignore the common name entirely. A certificate whose SAN list is empty is treated as covering nothing, regardless of what its common name says.

As few as possible. Every extra name is a name that must be tracked, renewed, and revoked, and each one is a potential target for issuance you did not request. Wildcards reduce the count substantially since one entry covers a whole label, though remember the single-label limit. Many internal certificates accumulate dozens of names over years as hosts come and go.

Yes, through a SAN entry of the IP type rather than a DNS name. It matters for infrastructure certificates and for pinning rules expressed as addresses. Note that the two types do not cover for each other: a certificate valid for an IP address is not automatically valid for a hostname pointing at that address, and browsers require name matching rather than address matching.

They identify a resource by URI rather than by host, and they appear mostly in internal PKI — service mesh certificates, device identity, and similar schemes where a URI is the natural identifier. Public web certificates almost never carry them. Seeing one is not a warning sign; it is usually a sign the certificate was issued by an internal or specialised authority.

Because renewal reissues whatever the current request contains, and authorities generally keep issuing for every name on the previous certificate unless you narrow the request. That is how certificates slowly accumulate names — decommissioned staging hosts, old regional endpoints. Periodic review with this page is how you find them, and reissuing with a clean list is the fix.

What Is Extracted

Modern validation ignores the common name entirely and uses the subject alternative name list. This page reads that list and separates it by type, because the types carry different meaning.

1DNS names, which is what browsers check for web certificates. These are the names a certificate can validate for, and the list is reported in full.
2IP addresses, which matter for certificates issued to bare hosts and for pinning rules that reference addresses rather than names. A certificate can cover an IP without covering any hostname at all.
3URIs and other name types, which are used less often but are legitimate content — for internal services, for S/MIME email identity, and for device certificates.

The wildcard count is reported alongside the names, because coverage is the practical question: a certificate listing forty names is a liability as well as an asset, since every one of them must be reissued to add or remove. The subject common name is read too, for reference, but modern clients ignore it.

Tips & Best Practices

•Extract SANs to understand certificate domain coverage
•Use SAN extraction for certificate inventory and documentation
•Verify SANs match your intended domain coverage
•Monitor SAN changes during certificate renewals

Technical Details

Extraction: Subject Alternative Name (SAN) extraction and analysis
Types: DNS names, IP addresses, email addresses, URIs
Validation: SAN format and content validation
Output: Extracted SAN list with type and validation status