Just as a follow up, these two certificates (with www.intesasanpaolovita..biz) were revoked on 19 July 2017. See http://ca.intesasanpaolo.com/portalCais0/crl/servext2.crl.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Tuesday, July 18, 2017 9:54 AM To: Jakob Bohm <jb-mozi...@wisemo.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificate with invalid dnsName issued from Baltimore intermediate On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/07/2017 21:27, Nick Lamb wrote: > > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson wrote: > >> Thank you for bringing this to our attention. We have contacted > >> Intesa > Sanpaolo regarding this error and have asked them to correct it as > soon as possible. > > > > "Correcting" the error is surely the smaller of the two tasks ahead. > > > > Depends if the only error is allowing double dots (while correctly > validating the domain as if spelled without the extra dot). Things > are much worse if double dots bypass domain validation completely. > > Since at least two CA systems have now been found to accept double > dots, where only single dots should be allowed, it is reasonable to > assume that some relying parties also allow double dots. It is not reasonable to conclude there is a pattern based on two samples, nor is it reasonable to conclude there is a pattern in an unrelated system. If you are aware of any relying party libraries based on CA validation libraries, that would be useful in establishing the reasonableness of the conclusion. This makes it > essential that any certificates with this syntax error have been > completely validated for the equivalent single-dotted name. > > I also notice that this is apparently an unconstrained > intermediate/SubCA. > > Since this appears to be a certificate for the cert holders own > domains, it is also possible domain validation was done manually, as > in "we know first hand that we control these domains", making this an > OV cert, not a DV cert. All OV certs are DV certs - they are subsets. Perhaps you're confusing DNS validation done at an Authorization Domain Name, rather than FQDN. That would be consistent with allowing the customer to enter labels below the validated domain (under 3.2.5 of the BRs), but not validating it's a valid DNS label or well formed domain name. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
