Okay that seems like an issue as to me that says that this could have
happened to any domain and not just in-addr.arpa?
- Cynthia
On 2019-02-27 01:55, Jeremy Rowley via dev-security-policy wrote:
From our side, a validation agent weirdly scoped the domain, saying that the
domain was approved using an email to ad...@in-addr.arpa. However, the email
clearly went to ad...@5.168.110.79.in-addr.arpa. 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 <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
