>From our side, a validation agent weirdly scoped the domain, saying that the >domain was approved using an email to [email protected]. However, the email >clearly went to [email protected]. We're looking to see 1) how >did the validation staff override the domain approval scope and 2) did anyone >in validation ever do this before. Once we complete that search, we'll be able >to file a bug report and give you more information on what exactly went wrong.
.arpa is in IANA's root zone per https://www.iana.org/domains/root/db. Jeremy -----Original Message----- From: dev-security-policy <[email protected]> On Behalf Of Cynthia Revström via dev-security-policy Sent: Tuesday, February 26, 2019 4:17 PM To: Matthew Hardeman <[email protected]> Cc: [email protected]; [email protected] 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 > <[email protected] > <mailto:[email protected]>> wrote: > > Thanks Cynthia. We are investigating and will report back shortly. > ________________________________ > From: dev-security-policy > <[email protected] > <mailto:[email protected]>> on behalf > of Cynthia Revström via dev-security-policy > <[email protected] > <mailto:[email protected]>> > Sent: Tuesday, February 26, 2019 12:02:20 PM > To: [email protected] > <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> > 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 > [email protected] > <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > [email protected] > <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
