What happens to an existing certificate for *.example.com when example.com is added to the Public Suffix List?
Will the wildcard certificate be immediately revoked, or does it simply fail to renew?
4 Likes
Following this thread for the answer! I have no idea what LetsEncrypt will do, but I do know many browsers will apply increased sandboxed rules to those suffixes once they pick up the change.
3 Likes
well... if example.com gets added to the public suffix list, you can still get certificates for example.com -- what you cannot do is get a certificate for a tld suffix (com., co.uk.), but private suffixes should be fair game.
the answer probably is "nothing happens"
4 Likes
I think you missed the inherent security risk in what the OP brought up. Upon inclusion to the PSL, the entity possessing the *.example.com certificate could be completely independent from any entities possessing {subdomain}.example.com certificates and should be expected to be different. That situation is highly similar to the loss-of-control of a PrivateKey/Certificate pairing - as it would allow the entity controlling the wildcard certificate the ability to decrypt traffic for the public domain users.
I expect ISRG to either revoke the certificate or let the renewal lapse and prevent any future wildcard certificates from being issued to that domain. Anything else would be highly problematic from a security standpoint.
Flagging @JamesLE and @aarongable who have been active here lately. Hopefully one of them has an idea.
4 Likes
Yes, and it's not different than a normal tld suffix. If I control your DNS I can point your domain wherever I want, I don't need a wildcard, I can http-01 validate whatever.
4 Likes
boulder/iana.go at main · letsencrypt/boulder · GitHub ExtractSuffix function at the end.
rule := publicsuffix.DefaultList.Find(name, &publicsuffix.FindOptions{IgnorePrivate: true, DefaultRule: nil})
boulder's policy agent will ignore private section of public suffix list, unlike ratelimiting base domain calculation.
7 Likes
Interesting. In another forum I was pointed to the Baseline Requirements [PDF]. The relevant section, which seems to match the code, is:
3.2.2.6 Wildcard Domain Validation
Before issuing a Wildcard Certificate, the CA MUST establish and follow a documented procedure that determines if the FQDN portion of any Wildcard Domain Name in the Certificate is “registry‐controlled” or is a “public suffix” (e.g. “.com”, “.co.uk”, see RFC 6454 Section 8.2 for further explanation).
If the FQDN portion of any Wildcard Domain Name is “registry‐controlled” or is a “public suffix”, CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue “.co.uk” or “.local”, but MAY issue “*.example.com” to Example Co.).
Determination of what is “registry‐controlled” versus the registerable portion of a Country Code Top‐Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a “public suffix list” such as the Public Suffix List (PSL), and to retrieve a fresh copy regularly.
If using the PSL, a CA SHOULD consult the “ICANN DOMAINS” section only, not the “PRIVATE DOMAINS” section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which are listed in the “ICANN DOMAINS” section. A CA is not prohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is demonstrated in an appropriate way.
So issuing wildcard certs for a domain on the "private domains" section of the PSL is allowed, contrary to what I initially believed.
If a domain is added to the "ICANN domains" section of the PSL, it appears revocation is appropriate:
1.2.2 Relevant Dates
Compliance Section(s) Summary Description (See Full Text for Details)
...
2013‐09‐01 3.2.2.6 CAs SHALL revoke any certificate where wildcard character occurs in the first label position immediately to the left of a “registry‐controlled” label or “public suffix”
Thanks for the replies!
5 Likes
So... can a CA issue a certificate for *.com to Verisign?
3 Likes
This isn't quite accurate: That's in the "relevant dates" section because it represents a transition. On that date, the issuance of wildcard certificates such as *.public.suffix became disallowed. As such, on that date, it was required that any such existing certificates be revoked. It is not an ongoing requirement.
The ongoing requirement is what you quoted above, in Section 3.2.2.6:
If the FQDN portion of any Wildcard Domain Name is “registry‐controlled” or is a “public suffix”, CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace.
So the only ongoing requirement is "do not issue", not "and revoke anything for which the PSL status changes".
9 Likes
Makes sense, thanks for clarifying.
But is "do not issue" actually an ongoing requirement, in light of being listed in "PRIVATE DOMAINS" and not "ICANN DOMAINS"? From 3.2.2.6:
If using the PSL, a CA SHOULD consult the “ICANN DOMAINS” section only, not the “PRIVATE DOMAINS” section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which are listed in the “ICANN DOMAINS” section. A CA is not prohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is demonstrated in an appropriate way.
The code does appear to make this distinction:
5 Likes
Sorry, yes, I was using the phrase "public suffix" to refer specifically to the "ICANN DOMAINS" section of the PSL. Let's Encrypt only references the ICANN DOMAINS section when determining if issuance for a given domain is allowed.
Let's Encrypt does reference the "PRIVATE DOMAINS" section of the PSL for the purpose of calculating rate limits, but not for anything else.
9 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.