On 27/02/2019 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.
While there is no current use, and the test below was obviously
somewhat contrived (and seems to have triggered a different issue),
one cannot rule out the possibility of a need appearing in the
future.
One hypothetical use would be to secure BGP traffic, as certificates
with IpAddress SANs are less commonly supported.
Here this was clearly achieved by creating a CNAME record for
69.168.110.79.in-addr.arpa pointed to 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]> wrote:
Thanks Cynthia. We are investigating and will report back shortly.
________________________________
From: dev-security-policy <[email protected]>
on behalf of Cynthia Revström via dev-security-policy <
[email protected]>
Sent: Tuesday, February 26, 2019 12:02:20 PM
To: [email protected]
Cc: [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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
