Skip to content
This repository has been archived by the owner on Jun 7, 2019. It is now read-only.

Publicsuffix check alerts on wildcards with base domains in the "private domains" section #17

Open
jsha opened this issue Mar 27, 2018 · 1 comment

Comments

@jsha
Copy link
Contributor

jsha commented Mar 27, 2018

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

@vanbroup
Copy link
Contributor

@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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants