Re: Possible violation of CAA by nazwa.pl
Yes, I thought there was an exemption for that also. The A-DNS operator could always just momentarily change the records to authorize anyway, so why bother with the check? On Wed, Jul 25, 2018 at 4:21 PM, Quirin Scheitle via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Michel, > > > On 23. Jul 2018, at 22:36, michel.lebihan2000--- via dev-security-policy > wrote: > > > > I think my domain registrar just violated my CAA by issuing that > > certificate. Where they allowed to issue this certificate? > > the name servers for lebihan.pl are ns[1-3].nazwa.pl. , which indicates > that your hoster (nazwa.pl) also operates your name servers. > > The certificate is issued by nazwaSSL, which links to Certum’s roots. > > Checking against current version 1.6.0 of BRs, Sec 3.2.2.8 reads: > > "CAA checking is optional if the CA or an Affiliate of the CA is the DNS > Operator (as defined in RFC 7719) of the domain's DNS.” > > So, if am not mistaken at some step, this is probably OK per current CAB > BRs. > > Kind regards > Quirin > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible violation of CAA by nazwa.pl
Hi Michel, > On 23. Jul 2018, at 22:36, michel.lebihan2000--- via dev-security-policy > wrote: > > I think my domain registrar just violated my CAA by issuing that > certificate. Where they allowed to issue this certificate? the name servers for lebihan.pl are ns[1-3].nazwa.pl. , which indicates that your hoster (nazwa.pl) also operates your name servers. The certificate is issued by nazwaSSL, which links to Certum’s roots. Checking against current version 1.6.0 of BRs, Sec 3.2.2.8 reads: "CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS.” So, if am not mistaken at some step, this is probably OK per current CAB BRs. Kind regards Quirin ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Possible violation of CAA by nazwa.pl
Hello, My domain registrar who is also a certificate authority just issued a precertificate (visible in CT logs) and a valid certificate for my domain. This is part of their new offer to automatically offer free certificates for all of their domains: https://www.nazwa.pl/certyfikaty-ssl/ I had a CAA record that only allowed letsencrypt.org to issue certificates for my domain: `lebihan.pl.3600IN CAA 0 issue "letsencrypt.org"` I think my domain registrar just violated my CAA by issuing that certificate. Where they allowed to issue this certificate? I also read that is is not recommended for certificate authorities to generate private keys and certificates for clients. Shouldn't they only sign certificate requests? The precertificate is visible on Facebook Surveillance Certificate Transparency: https://developers.facebook.com/tools/ct/search/?query=lebihan.pl The issuer is `C=PL, O=nazwa.pl sp. z o.o., OU=http:, nazwa.pl, CN=nazwaSSL`. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Revocations Due to a Variety of Issues
On Friday, July 20, 2018 at 9:39:04 PM UTC-7, Peter Bowen wrote: > On Fri, Jul 20, 2018 at 6:39 PM Daymion Reynolds via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > The certificates were identified by analyzing results from both zlint and > > certlint. We also verified all lint findings against current and past BRs. > > We discovered multiple defects with the linters, and submitted pull > > requests to correct them. See below. > > > > CertLint PRs to correct issues: > > > > In Progress, will publish if requested. > > > > Yes, I would very much like to have either PRs or just a list of issues. > > > > | e_dnsname_not_valid_tld, | > > | > > |e_subject_common_name_not_from_san,| > > | > > |e_dnsname_bad_character_in_label |4 > > |*7/5/18 11:48 | > > > > > > | e_subject_common_name_not_from_san, | | > > | > > |e_dnsname_bad_character_in_label |28 > > |*7/9/18 21:12 | > > > > > > *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. > > Thanks, > Peter 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. Thanks, Joanna ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
