An organization wants a single certificate covering shop.example.com, mail.example.com, and www.example.com, and it expects to add more first-level subdomains of example.com over time. Which certificate type fits BEST?
Select an answer to reveal the explanation.
Short Explanation
A wildcard is like a key that fits every door on one hallway. Any name you add at that same level is already covered. Just remember it won't reach down another level, so don't expect it to cover a.b.example.com.
Full Explanation
A wildcard certificate uses an asterisk in the leftmost label of the domain name, such as *.example.com, and is valid for any single label in that position. It therefore covers shop, mail, www, and any first-level subdomain added later without reissuing the certificate. The asterisk matches only one level, so names like dev.shop.example.com are not covered, and many organizations weigh this convenience against the risk that one compromised private key affects every subdomain. A single-name certificate for the bare domain does not cover any subdomain; HTTP redirects cannot help, because the TLS handshake for the subdomain occurs before any redirect, and the browser would warn about the name mismatch. A self-signed root certificate creates a private trust anchor that public browsers do not trust, which is unsuitable for public services and is not a certificate type for naming coverage. A code-signing certificate is used to sign software and scripts, not to authenticate web server names in TLS. Exam caveat: a certificate with several subject alternative names can also cover listed names, but it must be reissued whenever a new name is added, which is why expected growth points to a wildcard. Operational check: limit how many servers hold the wildcard private key, store it in protected storage, and track every server where it is deployed so it can be replaced quickly if compromised.