SAN Extractor

The SAN Extractor pulls all Subject Alternative Names from X.509 certificates, providing a clean list of every hostname, IP address, email address, and URI the certificate is valid for -- critical because modern browsers use SANs exclusively for hostname validation, ignoring the Common Name field. Paste one or more PEM certificates and get a complete inventory of covered identities.

Understanding Subject Alternative Names

Subject Alternative Names are the way modern certificates declare which identities they protect. Every time a browser connects to an HTTPS site, it checks the certificate's SAN extension to see if the domain in the address bar is listed. If it is not, the connection fails with a hostname mismatch error -- even if the domain appears in the older Common Name field. This has been the behavior in Chrome since version 58 (2017), and all other major browsers follow the same rule.

For sysadmins, the practical impact is significant. You need to know exactly which domains a certificate covers before deploying it, before renewing it, and when troubleshooting connection failures. A certificate for www.example.com might also cover example.com, api.example.com, and cdn.example.com, or it might only cover the bare www subdomain. You cannot tell from the certificate file name or the Common Name alone. The SAN extension is the authoritative source of truth for what a certificate protects.

This extractor pulls every SAN entry from one or more certificates and presents them as a clean, organized list. For multi-certificate input (like a chain or a bundle of unrelated certificates), it shows which SANs come from which certificate. This makes it easy to audit your certificate coverage across an entire infrastructure -- paste all your certificates, and you immediately see every domain, IP address, and identity that is protected.

How to Extract SANs from a Certificate

1. Paste one or more PEM-encoded certificates (starting with -----BEGIN CERTIFICATE-----)
2. The tool extracts and lists all Subject Alternative Names, organized by type
3. Review the SAN list for completeness and accuracy
4. Copy the output as a list, regex pattern, or configuration snippet

Example SAN Extraction

From a multi-domain certificate:

Certificate: CN=www.example.com

Subject Alternative Names:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: *.staging.example.com
  IP:  203.0.113.50

SAN Types

Multi-Certificate Output

When pasting a bundle with multiple certificates, the extractor shows which SANs come from which certificate:

When to Use This Tool

• Pre-renewal domain audit -- list all domains covered by an expiring certificate to ensure the renewal request includes every SAN
• Certificate coverage mapping -- document which certificates protect which domains across your infrastructure
• Wildcard coverage verification -- confirm that wildcard certificates (*.example.com) cover the expected subdomains and identify what they do not cover (e.g., sub.sub.example.com)
• Migration planning -- extract SANs from existing certificates when migrating to a new CA or consolidating certificates
• Security review -- identify unexpected domains in a certificate that could indicate misconfiguration or compromise
• Troubleshooting hostname mismatch -- verify that the domain causing a TLS error is actually listed in the certificate's SANs

How Subject Alternative Names Work

The SAN extension (OID 2.5.29.17) was introduced to overcome limitations of the Common Name field. While CN could only hold a single hostname, the SAN extension supports multiple names and different name types.

CN vs. SAN: Current Browser Behavior

Since 2017, major browsers have deprecated the Common Name for hostname matching:

• Chrome 58+ -- ignores CN entirely; only checks SANs
• Firefox 48+ -- ignores CN if SANs are present
• Safari -- follows the same pattern

This means a certificate with CN=example.com but no DNS:example.com SAN entry will produce a hostname mismatch error in modern browsers. Always ensure every domain appears in the SAN extension.

Wildcard Certificate Scope

Wildcard SANs follow specific matching rules:

Key rules:

• Wildcards only match one level of subdomain
• Wildcards must be the leftmost label (*.example.com, not www.*.com)
• The bare domain (example.com) is not matched by *.example.com -- it must be listed as a separate SAN

Managing SANs in Practice

The most common SAN-related mistake is forgetting the bare domain. If your users access both www.example.com and example.com, both must appear as separate SAN entries. A wildcard *.example.com covers www.example.com but not example.com itself. This catches many teams by surprise when they switch from a wildcard-only certificate to one that they expect to cover the apex domain. Always include both example.com and *.example.com (or www.example.com) as separate entries.

For organizations with many subdomains, deciding between a wildcard certificate and a multi-SAN certificate is an important architectural choice. Wildcard certificates (*.example.com) are convenient because you do not need to list every subdomain, but they cannot cover deeper subdomains like api.v2.example.com or the bare domain. Multi-SAN certificates list every domain explicitly, which gives you complete control but requires updating the certificate whenever you add a new subdomain. Many organizations use a wildcard for dynamically created subdomains and a separate multi-SAN certificate for their primary domains.

When auditing certificate coverage before renewals, extract the SANs from your expiring certificate and compare them against your DNS records. It is surprisingly common to discover that a certificate was issued two years ago with SANs that no longer match your current infrastructure. New subdomains were added, old ones were retired, and the certificate was never updated. This audit step prevents the frustrating situation of deploying a renewed certificate only to discover it does not cover a subdomain that was added after the original certificate was issued.

Frequently Asked Questions

Why does my certificate show domains I did not request? Some CAs automatically add both the bare domain and www variant. For example, requesting a certificate for example.com may result in SANs for both example.com and www.example.com. Additionally, multi-domain (UCC/SAN) certificates may include domains from previous orders if they were renewed rather than reissued.

How many SANs can a single certificate have? There is no hard limit in the X.509 standard, but practical limits exist. Let's Encrypt allows up to 100 SANs per certificate. Commercial CAs typically support 25--250 SANs depending on the product. Very large SAN lists increase certificate size and TLS handshake time.

Does a wildcard certificate need the bare domain as a separate SAN? Yes. A wildcard SAN *.example.com does not match the bare domain example.com. If you need both *.example.com and example.com to work, both must appear as separate SAN entries in the certificate.

Can a certificate have both DNS and IP SANs? Yes. A single certificate can include both DNS names and IP addresses as SANs. This is useful for services that are accessed both by hostname and by IP address. However, most CAs require additional validation for IP address SANs, and Let's Encrypt does not currently issue certificates with IP SANs.

Why does my certificate show "hostname mismatch" even though the CN matches? Modern browsers (Chrome 58+, Firefox 48+) ignore the Common Name for hostname validation and only check Subject Alternative Names. If your domain appears in the CN but not as a DNS SAN entry, browsers will reject the certificate. Ensure every domain is listed as a SAN entry, not just in the CN.

How do SANs work with multi-level subdomains? A wildcard *.example.com only matches one level of subdomain. It covers www.example.com and api.example.com but does not cover api.v2.example.com. For multi-level subdomains, you need either an explicit SAN entry for each one or a separate wildcard like *.v2.example.com.

Related Tools

• X.509 Certificate Viewer - View all certificate fields, not just SANs
• Certificate Expiry Checker - Check when certificates covering your domains expire
• CSR Viewer - Verify requested SANs in a CSR before submitting to a CA
• PEM Bundle Splitter - Split a chain to extract the leaf certificate containing the SANs
• Public Key Extractor - Extract the public key for certificates covering your domains