You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 7, 2019. It is now read-only.
Per the BRs, when checking for "registry-controlled" suffixes, "a CA SHOULD consult the 'ICANN DOMAINS' section only." However, certlint currently consults both the "ICANN DOMAINS" section and the "PRIVATE DOMAINS" section.
3.2.2.6 Wildcard Domain Validation
Before issuing a certificate with a
wildcard character () in a CN or subjectAltName of type DNS-ID, the
CA MUST establish and follow a documented procedure that determines
if the wildcard character occurs in the first label position to the
left of a “registry-controlled” label or “public suffix”
(e.g. “.com”, “.co.uk”, see RFC 6454 Section 8.2 for
further explanation). If a wildcard would fall within the label
immediately to the left of a registry-controlled or 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.). Prior to September 1, 2013, each CA MUST revoke any valid
certificate that does not comply with this section of the Requirements.
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 http://publicsuffix.org/ (http://publicsuffix.org/)
(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
The text was updated successfully, but these errors were encountered:
@jsha a good point, the private domains are included to cover some edge cases such as the domains that are sold by CentralNic and others where the purpose of the domain is the be equal to an ICANN delegated name but they don't fall under the ICANN regulation.
Strictly this is not against the BR as it's hard to check, but in these cases, I regularly prefer to test against the biggest abuse impact.
Maybe it's an idea to return a warning instead of an error when the suffix is not a delegated one by ICANN?
A few examples from CentralNic:
ae.org
ar.com
br.com
cn.com
com.de
com.se
de.com
eu.com
gb.com
gb.net
hu.com
hu.net
jp.net
jpn.com
kr.com
mex.com
no.com
qc.com
ru.com
sa.com
se.net
uk.com
uk.net
us.com
uy.com
za.bz
za.com
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Per the BRs, when checking for "registry-controlled" suffixes, "a CA SHOULD consult the 'ICANN DOMAINS' section only." However, certlint currently consults both the "ICANN DOMAINS" section and the "PRIVATE DOMAINS" section.
The text was updated successfully, but these errors were encountered: