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
