How do multi-domain and wildcard certificates work with verification levels?

　　In SSL/TLS certificate selection practice, domain coverage (single domain, multiple domains, wildcard) and authentication levels (DV, OV, EV) are two independent dimensions. However, their combination is not arbitrary but constrained by technical specifications, industry standards, and CA/Browser Forum baseline requirements. Understanding "how multi-domain certificates work with authentication levels" and "which authentication levels wildcard certificates support" is a necessary prerequisite for making a reasonable certificate selection.

　　I. Multi-Domain Certificates (SAN/UCC) and Authentication Level Coordination

　　Multi-domain certificates, also known as Unified Communications Certificates (UCC) or Subject Alternate Name (SAN) certificates, achieve the function of protecting multiple fully qualified domain names (FQDNs) with a single certificate by embedding the SAN extension field in the X.509 certificate structure. The SAN field can contain regular domain name entries, wildcard entries, or a mixture of both. This design makes a single certificate like a "master key" that can open multiple doors, eliminating the need for a separate certificate for each domain.

　　1. Verification Levels: Full Coverage and Consistency of DV, OV, and EV

　　The core feature of multi-domain certificates is that all domains listed in the SAN field share the same certificate expiration date and verification level. This means:

　　DV-level multi-domain certificates: Only Domain Ownership Verification (DCV) needs to be completed for each domain listed in the certificate. Verification methods include DNS TXT records, HTTP file uploads, or confirmation via a specified email address. Once all domains are verified, the certificate can be issued. Suitable for multi-domain scenarios that do not involve sensitive data.

　　OV-level multi-domain certificates: In addition to verifying the ownership of each domain, the CA also needs to conduct strict business information verification of the applicant organization, including the company's registered name, registered address, business status, and contact information. All domains listed in the certificate must belong to the same organization. The issuance period is generally 1 to 3 business days.

　　EV-level multi-domain certificates: Can only be issued after all domain ownership verification is completed and the organization's identity passes the EV-level audit. The EV multi-domain certificate audit process is the most rigorous—it requires verifying the ownership of each domain one by one, while ensuring that all domains belong to the same legal entity. The issuance cycle is generally 3 to 7 business days. EV multi-domain certificates support up to 500 SAN entries and are suitable for highly sensitive scenarios such as finance and payments.

　　2. Key Limitation: "Attribution Consistency" Requirement for EV Multi-Domain Certificates

　　The CA/Browser Forum's EV guidelines explicitly stipulate an important limitation: for EV-level multi-domain certificates, all domains listed in the certificate must be legally owned or controlled by the same organization. Domains registered under different entities cannot be included in the same EV certificate. The logic behind this requirement is that the core value of an EV certificate is to demonstrate to end users the most rigorously verified organizational identity. If the same certificate simultaneously covers domains of different legal entities, this identity endorsement becomes meaningless.

　　To efficiently manage multi-domain verification for EV certificates, some CAs provide an "anchor certificate" mechanism. By pre-listing all domains requiring EV protection in an anchor certificate and completing a one-time verification, subsequent EV certificate applications for these domains can avoid repeated verification processes, significantly improving issuance efficiency.

　　3. The Possibility of Hybrid Authentication Types

　　It's worth noting that, strictly speaking, "hybrid authentication types" don't technically exist—because once a multi-domain certificate selects an authentication level, all domains within it accept the same level of authentication. However, there's a flexible practice in the industry: different domains can use multi-domain certificates with different authentication levels, managed independently. For example, core transaction domains use EV-level multi-domain certificates, while peripheral business domains use OV-level or DV-level multi-domain certificates. This "certificate combination strategy" achieves differentiated configuration of authentication levels at the organizational level while maintaining consistency within each certificate.

　　II. The Coordination of Wildcard Certificates and Authentication Levels

　　Wildcard SSL certificates protect all first-level subdomains under the same main domain by using the asterisk (*) wildcard in the Common Name or SAN field. For example, *.example.com can cover www.example.com, mail.example.com, api.example.com, etc., but does not include third-level or deeper subdomains (such as a.b.example.com), nor other main domains. This characteristic makes wildcard certificates particularly suitable for organizations with large-scale subdomain architectures.

　　1. Supported Levels: DV and OV, EV not supported

　　This is the most critical constraint of wildcard certificates: wildcard certificates only support two levels: DV (Domain Verification) and OV (Organization Verification). EV (Extended Verification) is not supported in any mainstream CA product systems.

　　DV-level wildcard certificates: Only verify ownership of the main domain. Subdomains are automatically overridden by the wildcard, eliminating the need for individual verification. Issuance time is in minutes, suitable for testing environments, personal projects, and scenarios where organizational identity is not strictly required.

　　OV-level wildcard certificates: In addition to domain verification, organizational identity verification (business registration information, registered address, callback, etc.) is required. Verification time is generally 1 to 2 business days. The organization name is displayed in the certificate details, suitable for internal enterprise systems, SaaS platforms, and other multi-subdomain scenarios requiring demonstration of organizational credibility.

　　EV level not supported: EV wildcard certificates are explicitly prohibited by the baseline requirements of CAs/Browser Forums. According to Article 8.1.1 of the EV Guidelines, the domain field of an EV certificate must not contain wildcard entries. This is because EV certificates require independent, highest-level authentication for each protected domain, and wildcards essentially mean that the CA cannot foresee all potentially added subdomains in the future, and therefore cannot perform rigorous EV-level verification on each one.

　　2. Technical Limitations: Only for First-Level Subdomains

　　The wildcard * only matches the leftmost domain tag level. For *.example.com, it can protect shop.example.com, but not a.shop.example.com. To protect multiple levels of subdomains, multi-level wildcards (such as *.*.example.com) should be used, but the compatibility of this configuration is limited, and there is still no EV-level option for this configuration.

　　The combination of multi-domain certificates and authentication levels is essentially a trade-off between "breadth of coverage" and "depth of identity trust." Multi-domain certificates cover all levels of DV, OV, and EV, but the EV level mandates consistent organizational affiliation across all domains. Wildcard certificates offer flexibility through unlimited subdomain expansion, but at the cost of sacrificing EV level coverage. Multi-domain wildcard certificates provide the most comprehensive coverage, provided they accept DV or OV level authentication.

　　The key to choosing the right certificate lies in: first, clarifying your domain architecture characteristics (single-domain/multi-domain/wildcard/combined forms); second, defining your business's actual requirements for authentication depth (basic encryption/organizational endorsement/highest level trust); and finally, finding the optimal balance between cost, security, and operational efficiency within technically permissible limits. When requirements are extremely complex, deploying multiple certificates of different levels and types is often a more pragmatic solution than pursuing a "one-certificate-for-all" approach.