https://bugzilla.mozilla.org/show_bug.cgi?id=1531817 has been created to track this issue.
On Wed, Feb 27, 2019 at 10:52 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Cynthia, > > We've figured out what happened with your certificate but are still > looking at whether other certificates were issued using the same process. I > don't have enough information to file an incident report yet, but I wanted > to give you the update I promised earlier. > > Basically, here's what happened: > 1. A validation agent took an email address provided during a chat session > with you and set that email as a WHOIS admin email address. This email > qualified as a constructed email (admin@domain) > 2. The system marked the WHOIS as unavailable for automated parsing > (generally, this happens if we are being throttled or the WHOIS info is > behind a CAPTCHA), which allows a validation agent to manually upload a > WHOIS document > 3. The WHOIS document uploaded was a screen capture of WHOIS information > that did not match the domain being requested but was close enough that the > mis-match went unnoticed. > 4. The validation agent specified the approval scope as id-addr.arpa which > is normal for a domain approved by the admin listed in WHOIS. As a > constructed email, the approval scope should have been limited to the scope > set by the constructed address. > 5. The validation agent specified that the email address listed in WHOIS > matched the email address provided by you (admin@domain) and sent the > email to authorize the legit cert > 6 . When the validation completed successfully, the validation authorized > your account for all certificates with the in-addr.arpa domain. This was > because the scope was improperly set based on the validation agent's > improper specification of the source of the email address. > 7. During the review, no one noticed that the WHOIS document did not match > the verification email nor did anyone notice that the email used for > verification was actually a constructed email instead of the WHOIS admin > email. > 8. The mis-issued certificate essentially "piggy-backed" on the previous > verification because of the erroneous approval scope set by the validation > staff. > > Make sense? > > We shut down manual WHOIS verification while we figure out how to improve > the process and eliminate validation mistakes like this. We'll post another > update after we figure out how to improve the process and after the data > review is complete. > > Jeremy > > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Cynthia Revström via dev-security-policy > Sent: Tuesday, February 26, 2019 4:17 PM > To: Matthew Hardeman <mharde...@gmail.com> > Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk > Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance > > I am not so sure that is proper to have .arpa domains in the SANs. > > But I think the larger issue I think is that this might allow for non > in-addr.arpa domains to be used as well. > > It was just that I just tried to get a cert for my domain for a test to > see if that would be issued. > > And upon verifying the domain via email, I saw that on the page linked in > the email it had an option along the lines of "Authorize in-addr.arpa for > all orders on account #123456" (not that exact text but the same meaning). > > Now I am not sure if this would work, but I suspect if for example I got > DNS control over cynthia.site.google.com, I could get a cert for > google.com if this is a systemic issue and not just a one off. > > - Cynthia > > On 2019-02-27 00:10, Matthew Hardeman wrote: > > Is it even proper to have a SAN dnsName in in-addr.arpa ever? > > > > While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it > > rarely has anything other than PTR and NS records defined. > > > > Here this was clearly achieved by creating a CNAME record for > > 69.168.110.79.in-addr.arpa pointed to cynthia.re <http://cynthia.re>. > > > > I've never seen any software or documentation anywhere attempting to > > utilize a reverse-IP formatted in-addr.arpa address as though it were > > a normal host name for resolution. I wonder whether this isn't a case > > that should just be treated as an invalid domain for purposes of SAN > > dnsName (like .local). > > > > On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy > > <dev-security-policy@lists.mozilla.org > > <mailto:dev-security-policy@lists.mozilla.org>> wrote: > > > > Thanks Cynthia. We are investigating and will report back shortly. > > ________________________________ > > From: dev-security-policy > > <dev-security-policy-boun...@lists.mozilla.org > > <mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf > > of Cynthia Revström via dev-security-policy > > <dev-security-policy@lists.mozilla.org > > <mailto:dev-security-policy@lists.mozilla.org>> > > Sent: Tuesday, February 26, 2019 12:02:20 PM > > To: dev-security-policy@lists.mozilla.org > > <mailto:dev-security-policy@lists.mozilla.org> > > Cc: b...@benjojo.co.uk <mailto:b...@benjojo.co.uk> > > Subject: Possible DigiCert in-addr.arpa Mis-issuance > > > > Hello dev.security.policy > > > > > > Apologies if I have made any mistakes in how I post, this is my first > > time posting here. Anyway: > > > > > > I have managed to issue a certificate with a FQDN in the SAN that I > do > > not have control of via Digicert. > > > > > > The precert is here: https://crt.sh/?id=1231411316 > > > > SHA256: > > 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1 > > > > > > I have notified Digicert who responded back with a generic response > > followed by the certificate being revoked through OCSP. However I > > believe that this should be wider investigated, since this cert was > > issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area > > that I do control though reverse DNS. > > > > > > When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed > > that the whole of in-addr.arpa became validated on my account, > instead > > of just my small section of it (168.110.79.in-addr.arpa at best). > > > > > > To test if digicert had just in fact mis-validated a FQDN, I > > tested with > > the reverse DNS address of 192.168.1.1, and it worked and Digicert > > issued me a certificate with 1.1.168.192.in-addr.arpa on it. > > > > > > Is there anything else dev.security.policy needs to do with this? > This > > seems like a clear case of mis issuance. It's also not clear if > > in-addr.arpa should even be issuable. > > > > > > I would like to take a moment to thank Ben Cartwright-Cox and > > igloo22225 > > in pointing out this violation. > > > > > > Regards > > > > Cynthia Revström > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > <mailto: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 > > <mailto: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 > _______________________________________________ > 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
