Our SAN Pattern Checker extracts and analyzes all Subject Alternative Names from an SSL certificate. It categorizes entries by type — DNS names, wildcard domains, and IP addresses — and identifies patterns in the SAN list. This is essential for understanding the full scope of domains a certificate covers and detecting potential gaps in coverage.
How to Use
1Enter the domain whose SAN patterns you want to analyze.
2Click "Check" to fetch and parse the certificate's SANs.
3Review the full list of DNS names, wildcards, and IPs.
4Identify patterns and check for any missing domains.
Use Cases
•Audit SAN coverage after certificate renewal
•Detect unexpected wildcard patterns in certificates
•Verify IP addresses are properly listed as SANs
•Catalog all domains protected by a multi-SAN certificate
Frequently Asked Questions
DNS names, wildcard domain patterns and IP address entries, each distinguished by type rather than lumped together. The distinction is worth having because browsers treat them differently: a certificate can be valid for a hostname and still fail for an IP address unless an IP entry is present, and many certificates people believe cover a host range do not cover it at all. Reading the breakdown shows exactly which kind of name is missing rather than just that something is.
With the asterisk prefix, as *.example.com, so the scope of the entry is visible in the list. A wildcard covers exactly one label beneath the domain, never the bare domain itself, and never two or more levels down, so seeing the entry written out makes it obvious at a glance whether the apex or a deep subdomain is actually covered. That is the distinction people most often get wrong, and it is much easier to spot when the pattern is shown rather than summarised as a count.
Yes, with a count and a breakdown by type, which is the more useful form. A certificate carrying two hundred entries is unusual and worth understanding before you rely on it: authorities price by name, browsers have their own limits on how many names they will process, and a long list is a sign the certificate may have been issued for a shared hosting environment rather than for you. The breakdown shows whether the entries are the ones you intended.
Broad wildcards and unexpected naming patterns draw attention because they widen what the certificate proves. An entry like *.com would cover an enormous number of hostnames and should never be issued, so seeing one in a certificate is a strong signal that something went wrong upstream. Entries for domains you do not recognise are flagged for the same practical reason: a certificate covering names you did not ask for is worth understanding before you rely on it.
Not by itself, but it widens what one key controls. A wildcard covering a hundred subdomains means a compromise of that key affects all of them at once, where individual certificates would contain the damage. For a service handling credentials or payments that distinction matters; for an internal estate it is often the right trade. What matters is being deliberate about it rather than accumulating wildcards by accident.
Homograph and confusion attacks are the concern: two names that render almost identically in a browser but are different domains. Certificate transparency logs help here because seeing an unexpected certificate for a similar-looking name is a real signal. The operational risk is more mundane — IDN names are stored in punycode, so matching them against hostnames during a migration is error-prone.
Few. Every name is something to track, renew and revoke, and each is a name that could in principle be certified by an authority you did not ask. Wildcards reduce the count substantially, subject to the single-label limit. Many certificates have accumulated names over years as hosts come and go, and periodic review is how the obsolete ones get found.
No. It reports what the certificate contains, which is not the same as what your estate needs. A name in a certificate may point at a decommissioned host, and that entry is a liability rather than an asset. To find them, cross-reference the name list against your actual inventory — the certificate tells you what could be valid, only the inventory tells you what should be.
Because renewal reissues whatever the current request contains, and authorities generally keep certifying every name from the previous certificate unless you narrow the request explicitly. Decided hosts are the usual case: nobody removes them because nobody notices them. Reviewing the name list periodically is the only way they get found, since nothing else about a certificate changes to flag them.
What Patterns Are Checked
Some name patterns are legal and unwise. This page identifies them in a certificate's subject alternative names.
1Identify wildcards and count them. A wildcard is legitimate but means one private key now controls every name it covers, so the count is worth knowing before you accept a certificate that has accumulated several.
2Identify internationalised names, which appear in Unicode form in the certificate and require the punycode equivalent to function. A certificate with IDN names is harder to audit because what you read and what resolves differ.
3Report the full name list, since the count of names is itself a finding. A certificate carrying dozens of names is a liability: each one is something to track, renew and revoke, and each is a name an authority could be asked to certify.
What is reported is what the certificate contains, not whether each name is currently in use. The expired staging host nobody remembers is exactly the kind of entry this page surfaces, and removing it takes one reissue.
Tips & Best Practices
•Analyze SAN patterns to understand certificate coverage across subdomains
•Use pattern analysis to identify certificate reuse or sharing
•Monitor SAN patterns for unauthorized domain additions
•Compare SAN patterns before and after certificate renewals
Technical Details
Analysis: Pattern matching and grouping of SAN entries Patterns: Wildcard, specific domain, and IP address patterns Grouping: Certificates grouped by common patterns Export: Pattern analysis results in CSV and JSON formats
