Our Multi-Domain Cert Checker validates SSL/TLS certificate coverage for multiple domains using a single Subject Alternative Name (SAN) certificate. Enter a primary domain, and the tool checks which domains are covered by the SAN list. This is essential for managing multi-domain wildcard certificates and ensuring all your domains are properly secured.
How to Use
1Enter the primary domain you want to check.
2Click "Check" to fetch the certificate and SAN list.
3Review all SANs listed on the certificate.
4Verify that all your domains are covered by the SAN list.
Use Cases
•Verify SAN coverage for multi-domain certificates
•Check if all subdomains are covered by a wildcard cert
•Audit certificate renewal to ensure no domains are missed
•Validate load-balanced server certificates cover all services
Frequently Asked Questions
It depends entirely on the authority, and the practical numbers range from three on an entry-level plan to a hundred or more on an enterprise one. The CA/Browser Forum limits lifetime rather than name count, so what you can include in one certificate is a commercial question rather than a technical limit. Two things are worth checking before you order: that your intended names are on the permitted list at all, and whether a wildcard will serve you better than enumerating every subdomain.
A wildcard entry, written with an asterisk in the leftmost label, covers every host at exactly one level beneath it, so *.example.com matches api.example.com and mail.example.com. It does not match deeper names such as a.b.example.com, and it never matches the bare example.com, which has to be listed separately and is the omission that catches people. One wildcard entry replacing twenty enumerated hosts is also usually cheaper, since authorities price by name.
Yes, enter them separated by commas or newlines and each is checked against the certificate in one pass. This is the workflow worth getting into the habit of, because certificates drift: a service is renamed, a region is added, a legacy hostname is retired, and the certificate quietly stops covering something. Checking the full list you actually serve, on a schedule, is what turns that from an outage into a ticket.
It is flagged, with the reason, so you can add it before the certificate expires rather than discovering it as a browser error. Worth reading which kind of mismatch it is: a name that is absent from the SAN list is a certificate problem, while a name that is present but failing validation usually means the certificate does not cover that specific form, such as a bare domain covered only by a wildcard or the reverse. Those need different fixes and are easy to conflate.
Because that is how users experience it. A wildcard covering most names and a specific certificate on one host is a perfectly normal arrangement, and a single connection to the apex would tell you nothing about the exception. Checking each host reports what it actually serves for its own name, which is the only thing that determines whether a user gets a valid certificate.
Usually a deployment that did not reach every node — one server in a pool, one region, one container that did not restart after the certificate changed. Each is individually healthy and collectively inconsistent, which is why it survives casual checking. A sweep across the whole estate after any certificate change is the reliable way to catch it.
No. A wildcard covers the names it lists but not the apex domain and not deeper subdomains, and hosts may serve a mix of the wildcard and individual certificates. Checking each host confirms what is actually served rather than what the wildcard should cover, and the difference between those two is where the problems are.
There is no artificial cap, but each host costs a connection and a timeout, and a failing host costs its full timeout. For a large estate, splitting into chunks keeps runs responsive and makes partial failure obvious rather than appearing to hang. Do it in chunks of a few dozen.
Check that specific host on its own, where the handshake debugger will show which stage failed. A DNS failure, a refused port and a wrong certificate are different problems with different owners, and the sweep result alone does not distinguish them. Fix it and re-run the sweep, since a fix applied to one node in a pool is easy to apply to only one.
How Multiple Hosts Are Checked
A certificate is only correct if it is served on every host that needs it. This page checks a list and reports each one separately.
1Connect to each host in the list and read the certificate it actually serves for that name. Connecting per host rather than assuming one certificate covers the set is the point — a wildcard covering some names and an individual certificate covering others is a normal arrangement.
2Report per host, including which certificate was served. Hosts that fail are named individually rather than summarised, because during a rollout the missed host is the thing you need to find.
3Flag inconsistency across the set, since hosts serving different certificates for the same estate usually means one node was missed. That single observation catches the most common deployment error.
This checks what each host serves now, which is what matters for users. It does not verify that a certificate covers every name it should — that is a separate question about the certificate's contents rather than its deployment.
Tips & Best Practices
•SAN certificates are more flexible than wildcard certificates for multiple domains
•Use multi-domain certificates to reduce certificate management overhead
•Ensure all domains in the SAN list are under your control
•Monitor all domains in the SAN list for expiry and security
Technical Details
SAN: Subject Alternative Name extension analysis Types: DNS names, IP addresses, email addresses, URIs Limit: Maximum 100 SAN entries per certificate Validation: Domain ownership verification for each SAN entry
