A wildcard certificate for *.example.com actually secures example.com itself, which trips up a lot of people.
Let’s watch one in action. Imagine we have a web server configured to use a wildcard certificate.
server {
listen 443 ssl;
server_name *.example.com example.com; # Crucially, both are listed
ssl_certificate /etc/ssl/certs/wildcard.example.com.crt;
ssl_certificate_key /etc/ssl/private/wildcard.example.com.key;
# ... other configurations
}
When a browser requests www.example.com, the server sees www.example.com matches *.example.com and presents the wildcard certificate. If the browser requests app.staging.example.com, it also matches *.example.com and the same certificate is presented. If, however, the browser requests example.com directly, the server_name directive needs to explicitly list example.com in addition to *.example.com for the server to respond with that certificate. Without example.com in server_name, the server wouldn’t know to answer for the bare domain, even though the wildcard certificate could technically cover it if the Certificate Authority (CA) issued it that way (which most do).
The problem a wildcard certificate solves is the administrative overhead of managing individual certificates for every subdomain. Before wildcards, if you had www.example.com, mail.example.com, and api.example.com, you’d need three separate SSL/TLS certificates. Each would have its own expiration date, renewal process, and installation. With a wildcard certificate, you get one certificate that covers all subdomains at a single level under a given domain.
Internally, the certificate itself contains a special entry in its Subject Alternative Name (SAN) field. Instead of listing every single subdomain explicitly, it includes an entry like DNS:*.example.com. When a client (like a browser) receives this certificate, it checks if the requested hostname matches any of the DNS entries in the SAN field. The matching logic is usually simple: if the requested hostname is sub.example.com, and the SAN contains *.example.com, the sub part is treated as the wildcard. This is why it only covers one level of subdomains by default; sub.another.example.com would not match *.example.com.
The exact levers you control are the domain name you purchase the wildcard for (e.g., *.example.com) and the server_name directive in your web server configuration. You must include the base domain (e.g., example.com) in the server_name directive if you want your server to respond to requests for that bare domain using the wildcard certificate. The CA’s role is to issue a certificate that adheres to the RFC standards for wildcards, ensuring it’s trusted by browsers and other clients.
The common misconception is that *.example.com automatically covers example.com. It doesn’t, at least not from the server’s perspective for serving the certificate. The certificate can be issued to cover the base domain, but the web server needs to be explicitly told to respond to requests for the base domain (example.com) using that certificate. This is why you’ll often see server_name *.example.com example.com; in Nginx or similar directives in Apache.
The next logical step is understanding how Extended Validation (EV) certificates work and why they are still relevant.