Security
Security
Breadcrumbs

Regulations for the use of wildcards

  • ENS (Royal Decree 311/2022)

    • Minimum requirement "Least privilege" (art. 20) and its operational translation [op.acc.4] in Annex II: limit privileges (and by analogy, the scope of credentials/keys) to what is strictly necessary. This is the basis for not accepting certificates with excessive scope. BOE

    • Protection of communications in Annex II ([mp.com.2] confidentiality and [mp.com.3] integrity and authenticity): requires properly configured TLS and robust identity verification (matching the certificate name with the service). BOE

  • IETF — RFC 9525 "Service Identity in TLS (obsoletes RFC 6125)"

    • Establishes that clients must validate the identity of the server against the certificate's identifiers (SAN: DNS-ID/IP/SRV/URI). It recommends requesting certificates with "as few identifiers as necessary to identify a single service"; if several services are served, multiple certificates are preferable to a single "catch-all" one. It also restricts the use of wildcards to the leftmost label. All of this supports requiring specific FQDNs per environment/service and avoiding broad wildcards. rfc-editor.org+1

  • NIST SP 800-52r2 (TLS)

    • Official TLS configuration guide: server authentication via its certificate and name validation in the Subject Alternative Name (SAN); basis for requiring that the certificate cover exactly the host you are connecting to. NIST Publicationscsrc.nist.rip

  • NIST SP 800-57 Pt.1 Rev.5 (key management)

    • To limit the impact of a possible breach, it recommends using different keys for different purposes and limiting the amount of information/services protected by a single key. A wildcard *.cliente.com typically reuses the same key across many subdomains, increasing the "blast radius". NIST Publications

  • OWASP TLS Cheat Sheet

    • "Use Correct Domain Names": the FQDN must be in the SAN and must match exactly the destination.

    • "Carefully Consider the use of Wildcard Certificates": wildcards should be used with great caution and not to cover zones with different trust levels.

    • "Client Certificates and mTLS": when applicable, mutual TLS for reciprocal authentication. cheatsheetseries.owasp.org

  • CA/Browser Forum — Baseline Requirements (v2.1.6)

    • Section 3.2.2.6 Wildcard Domain Validation: regulates and restricts the issuance of wildcards (e.g., prohibited on public suffixes). These are not exactly our cases, but it shows that the industry already limits and treats wildcards with special care, supporting the position of narrowing the scope. CA/Browser Forum