A wildcard SSL certificate secures a main domain and its first-level subdomains with one certificate. It simplifies administration when many subdomains share the same trust and ownership model. The main tradeoff is larger blast radius, so governance, key protection, and renewal discipline matter more than with separate certificates.
Expanded Definition
A wildcard SSL certificate is a public-key certificate that secures a primary domain and any first-level subdomain beneath it, such as api.example.com and mail.example.com. It is used when multiple hosted services share one organisational trust boundary and one operational owner. In NHI and certificate governance, the wildcard pattern matters because the certificate becomes a shared machine identity with broad reach rather than a narrowly scoped asset.
Definitions vary across vendors on how far the “wildcard” trust model should be extended in practice. The cryptographic mechanism is straightforward, but the governance model is not: one private key can unlock many endpoints, so RFC 6125 style name matching and NIST Cybersecurity Framework 2.0 style asset control both become relevant when organisations decide whether shared issuance is appropriate. NHIMG research on the Ultimate Guide to NHIs — What are Non-Human Identities shows how quickly machine identities outgrow manual oversight. The most common misapplication is using a wildcard certificate for unrelated applications that have different owners, because a single key compromise then expands across too many subdomains.
Examples and Use Cases
Implementing wildcard certificates rigorously often introduces a key distribution tradeoff, requiring organisations to weigh operational simplicity against a larger blast radius if the private key is exposed.
- A platform team uses one certificate for dev.example.com, staging.example.com, and prod.example.com when all environments are managed under the same control plane and renewal process.
- A SaaS provider terminates TLS for tenant-facing subdomains, but keeps certificate issuance constrained to a dedicated secrets manager and short renewal windows, aligning with machine identity governance guidance in the Critical Gaps in Machine Identity Management report.
- An internal API gateway uses a wildcard cert for service endpoints while enforcing separate access policy and logging at the gateway layer, so the certificate does not become the only security boundary.
- A CI/CD environment renews a wildcard certificate automatically, but only after approval from the workload owner and validation that the private key never leaves protected storage.
- A federated workload architecture prefers per-service certificates instead of a wildcard when subdomains map to distinct teams, because shared trust would blur ownership and complicate revocation.
For implementation context, SPIFFE is often used where service identity needs to be more granular than a wildcard certificate can provide, especially in zero trust environments.
Why It Matters in NHI Security
Wildcard certificates are not inherently weak, but they concentrate risk. If the private key is copied into build systems, shared across teams, or left in poorly governed secret storage, a single compromise can impact many production workloads at once. That is why certificate inventory, ownership, rotation, and revocation are NHI controls, not just TLS hygiene. NHIMG reporting on the Critical Gaps in Machine Identity Management report found that 53% of organisations have experienced a security incident directly related to machine identity management failures, underscoring how quickly certificate sprawl becomes an operational issue. In parallel, the Ultimate Guide to NHIs — What are Non-Human Identities shows that excessive privileges and weak visibility remain common patterns around non-human credentials.
Practitioners should treat wildcard issuance as a governance decision: if ownership is unclear, key protection is weak, or subdomains serve different trust domains, separate certificates are usually safer. Organisations typically encounter the true cost of wildcard sprawl only after a key leak or emergency renewal failure, at which point certificate scope becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Wildcard certs are shared machine identities whose key handling and scope must be controlled. |
| NIST CSF 2.0 | PR.AC-1 | Access to certificate private keys maps to identity and access control governance. |
| NIST Zero Trust (SP 800-207) | Zero Trust discourages broad trust boundaries created by shared certificates. | |
| NIST SP 800-63 | IAL2 | Identity assurance concepts inform how strongly workload and service identities are bound. |
| OWASP Agentic AI Top 10 | Agentic systems often consume TLS credentials that must not be broadly reusable. |
Inventory wildcard certs, restrict key access, and review whether shared scope is justified.
Related resources from NHI Mgmt Group
- How should security teams manage SSL certificate sprawl across large environments?
- How should security teams manage SSL certificate expiry before it causes outages?
- Why do SSL certificate problems keep recurring in mature environments?
- What breaks when an SSL/TLS certificate is installed incorrectly?
