Can whitelist be given for rDNS domains (we have our reasons) such as 9.3.4.4.c.1.7.0.a.2.ip6.arpa which would normally fail because of too many labels?
Hi @iovoid,
I don’t think Let’s Encrypt is willing to issue these certificates, because Let’s Encrypt declines to issue certificates for bare IP addresses; the proof of control for reverse DNS names seems to have essentially the same semantics or significance as proof of control for the corresponding IP address.
Apparently Comodo is willing to issue for reverse DNS names
https://crt.sh/?Identity=%.in-addr.arpa
https://crt.sh/?Identity=%.ip6.arpa
so perhaps you should consider getting your certificates from them.
The rDNS is a DNS zone delegation (unlike IP addresses) and I have full control of the zone. There is no problem with making non-ip.subdomain.9.3.4.4.c.1.7.0.a.2.ip6.arpa exist.
As a consequence of the delegation system, ip6.arpa proof of control are also a proof of control of a IP subnet
Seems I am not the first to do that https://crt.sh/?id=32094798
I agree with your analysis, but I don’t think Let’s Encrypt will be willing to issue these certificates.
Let's Encrypt did issue such certificates in the past for ipv4: crt.sh | 28831026
X509v3 Subject Alternative Name:
DNS:84.100.185.in-addr.arpa
DNS:85.100.185.in-addr.arpa
DNS:www.84.100.185.in-addr.arpa
DNS:www.85.100.185.in-addr.arpa
Probably because there is no issue with max labels (ipv4 format is per-octet and ipv6 is per-nibble). To fit in the 10-label space, you need a big ipv6 subnet
Let’s Encrypt initially issued for some .in-addr.arpa
domains because we hadn’t explicitly blocked it. However, when we later looked at the purpose of the .in-addr.arpa
domain, we concluded that issuing TLS certificates for that domain is not in the spirit of the RFCs defining it. You can see the details at https://github.com/letsencrypt/boulder/pull/2279.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.