Thank you for this report Daymion. 3 of the issues were recent:
| e_dnsname_not_valid_tld, |
|
|e_subject_common_name_not_from_san,|
|
|e_dnsname_bad_character_in_label |4
|*7/5/18 11:48 |
I think the "e_dnsname_not_valid_tld" errors are false positives. 5 of the
6 certificates [1] are for the new .llc TLD and according to WHOIS were
issued after the FQDN was registered. The TLD hasn't yet been added to
zlint [2], triggering the error. The last one looks like the punycode
encoding in the SAN is triggering the error for the .рф TLD.
The other two errors are the result of SAN encoding that is, as Peter
described, not strictly a policy violation.
For the older issues, it's nice to see these older (most likely SHA-1 and
thus untrusted) certificates being cleaned up, but again I don't see any
policies being violated:
|BR certificates must be 39 months in validity or less |27
|4/1/15 13:07 |
The BR language is: "Except as provided for below, Subscriber Certificates
issued after 1 April 2015 MUST have a Validity Period no greater than 39
months"
The other 3 issues stopped occurring before Mozilla required BR compliance.
My conclusion is that there is no action required on Mozilla's behalf.
- Wayne
[1] https://crt.sh/?zlint=798&iCAID=904&minNotBefore=2018-01-01
[2] https://github.com/zmap/zlint/blob/master/data/newgtlds.txt
On Thu, Jul 26, 2018 at 10:26 AM Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Jul 25, 2018 at 2:08 PM Joanna Fox via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Friday, July 20, 2018 at 9:39:04 PM UTC-7, Peter Bowen wrote:
> > > > *Total of 17 certificates issued in 2018 were revoked due to invalid
> > > > extended ascii characters. CertLint was not catching these issues,
> > which
> > > > would have prevented issuance. We have since remediated these
> > problems, and
> > > > are adding zLint to our certificate issuance process as a second
> check.
> > > > Issued in 2018 certificate serial numbers 4329668077199547083,
> > > > 8815069853166416488, 8835430332440327484, 13229652153750393997,
> > > > 12375089233389451640, 11484792606267277228, 11919098489171585007,
> > > > 9486648889515633287, 14583473664717830410, 7612308405142602244,
> > > > 4011153125742917275, 6919066797946454186, 15449193186990222652,
> > > > 14380872970193550115, 1792501994142248245, 12601193235728728125,
> > > > 10465762057746987360
> > > > Cert.sh was unavailable when this was crafted else I would provide
> > links
> > > > to the 4 certs which were CT logged.
> > >
> > >
> > > https://crt.sh/?id=294808610&opt=zlint,cablint is one of the
> > > certificates. It is not clear to me that there is an error here. The
> > DNS
> > > names in the SAN are correctly encoded and the Common Name in the
> subject
> > > has one of the names found in the SAN. The Common Name contains a DNS
> > name
> > > that is the U-label form of one of the SAN entries.
> > >
> > > It is currently undefined if this is acceptable or unacceptable for
> > > certificates covered by the BRs. I put a CA/Browser Forum ballot
> > forward a
> > > while ago to try to clarify it was not acceptable, but it did not pass
> as
> > > several CAs felt it was not only acceptable but is needed and
> desirable.
> > >
> > > If Mozilla (or another browser) puts forward a policy on this, I'm
> happy
> > to
> > > update certlint to reflect the poicy.
> >
>
>
> > Using the example provided of
> > https://crt.sh/?id=294808610&opt=zlint,cablint, the error to which we
> > were addressing is, “ERROR: Characters in labels of DNSNames MUST be
> > alphanumeric, - , _ or *”. RFC 5280 states that the SAN field can
> contain a
> > dnsName but it must be in the IA5String format. IA5String is defined as
> > the first 128 characters in the ASCII alphabet. Right now as this is
> > defined, it does not include international variance of ISO 646. Should
> we
> > revisit this issue to clarify if international characters should be
> > included? GoDaddy would be in support of adding this clarification.
>
>
> That error is coming from zlint and appears, from my reading, to be a bug
> in zlint. The DNSName entries in the SAN in that certificate only contain
> allowable characters. The commonName attribute value in the Subject does
> have characters that are not allowed in the DNSName entry, but commonName
> is allowed to be a utf8string, which allows these characters. Further the
> commonName contains a fully qualified domain name that also appears in the
> SAN, so that BR requirement is met.
>
> The challenge in this case is that the BRs do not specify the required
> encoding of domain names. This doesn't really matter when handling pre-IDN
> domain names, but with Internationalized Domain Names (IDNs), encoding does
> need to be specified. Until Mozil
