What is a wildcard certificate? How can a single certificate protect all subdomains?

　　When deploying HTTPS for a website, many people's first problem isn't how to apply for a certificate, but rather how to manage the increasing number of subdomains and their associated certificates.

　　Initially, there might be only one main site, such as example.com. Later, as business expands, pi.example.com, cdn.example.com, etc., appear, followed by backends, test environments, activity pages, and independent business lines. If a separate certificate is applied for for each subdomain, the management cost quickly increases: renewals are cumbersome, deployment is complex, and configuration is prone to errors.

　　This is where wildcard certificates come in. Simply put, one certificate matches multiple subdomains at the same level.

　　For example, a certificate issued to *.example.com can typically cover api.example.com and cdn.example.com. In other words, theoretically, any first-level subdomain under example.com can use this one certificate.

　　Many people, upon first reading this, will ask: Why can one certificate protect so many domains? How does the browser know it's legitimate?

　　The key is that the certificate doesn't just contain a fixed domain name; it contains a wildcard rule. Modern TLS certificates contain a crucial field called SAN (List of Names). When establishing an HTTPS connection, browsers match the domain name the user is accessing against the SAN list in the certificate.

　　For example, if the certificate contains `*.example.com`, when the browser accesses `api.example.com`, it checks if `api` is a first-level subdomain of `example.com`. If a match is found, the certificate is considered valid. In other words, the browser doesn't "recognize all subdomains," but rather matches according to wildcard rules.

　　However, there's a common misconception here: wildcards don't match infinitely.

　　For example, a `*.example.com` certificate can usually cover `api.example.com`, but generally cannot cover `test.api.example.com`, because that's already a second-level nested subdomain. Think of it this way: the `*` occupies only one tag position, not expands infinitely downwards. This is a common pitfall when deploying multi-level business domains.

　　Another common question is: can it protect the root domain? For example, `example.com`? The answer is usually no.

　　Because *.example.com matches "a prefix + example.com", while the root domain itself has no prefix.

　　Therefore, in actual applications, many people add both: example.com and *.example.com, so that both the main site and the first-level subdomain are covered.

　　Next, let's address a frequently asked question: Why does the certificate authority believe you have the right to apply for the entire wildcard?

　　The reason lies in the verification method.

　　Regular single-domain certificates can sometimes be verified via an HTTP file, meaning a verification file is placed in the website directory. However, wildcard certificates usually require DNS verification (DNS-01). That is, you need to add a specific TXT record to the domain's DNS.

　　The certificate authority will query:

　　_acme-challenge.example.com

　　If the record is correct, it proves that you do indeed control the DNS of this domain.

　　Why is this necessary? Because a wildcard means you are applying for the entire subdomain space. If verification relies only on a specific website directory, the security boundary is too weak. DNS control is typically closer to domain ownership, making it more suitable as a verification method. This is why many people find the process different from applying for a regular single-domain certificate when applying for a wildcard certificate for the first time.

　　From an operations perspective, the greatest value of wildcard certificates isn't actually "saving the cost of a certificate," but rather unified management costs.

　　For example, if you have a dozen or so business subdomains, deploying multiple certificates for each domain individually would result in inconsistent expiration dates, complex automatic renewal processes, and a risk of missed updates. Using wildcard certificates allows for unified issuance, deployment, and renewal, which is especially convenient for small to medium-sized businesses.

　　However, it's not without its costs. One of the biggest risks is centralized private keys. Because multiple subdomains share the same certificate, it means multiple services might hold the same set of private keys. If a machine is compromised and its private key is leaked, theoretically, other subdomains using that certificate will also be affected. This is why many large businesses, while perfectly capable of using wildcard certificates, don't bind all their services to the same certificate.

　　Furthermore, wildcard certificates aren't optimal for all scenarios. For example, some SaaS and multi-tenant platforms might be better suited to using SAN multi-domain certificates or dynamic certificate management, rather than simply using a wildcard to cover everything.

　　From a deployment perspective, the server itself does not "automatically recognize wildcards."

　　You still configure the certificate and private key in Nginx, Apache, or the load balancer just like you would with a regular certificate.

　　For example, in Nginx:

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/private.key;
}

　　If the certificate itself contains *.example.com, the browser will be able to perform a valid match when accessing it. That is, the wildcard logic occurs during the certificate verification phase, not the web service configuration phase.

　　Here's another practical example. Many people believe that "if you use wildcards, you don't need to worry about adding subdomains later." This statement is only half true. While certificate re-issuance is generally unnecessary at the certificate level, you still need to configure DNS resolution, web service virtual hosts, business access policies, and CDN origin pull rules. Therefore, it addresses "certificate management," not the "entire domain access process."

　　In short: wildcard certificates essentially use rules like *.example.com to include multiple first-level subdomains within the matching scope of the same TLS certificate. Browsers use the SAN field for domain matching, and certificate authorities verify your domain control through DNS verification. It truly solves the complexity of certificate management in multi-subdomain scenarios, not all HTTPS issues.