that’s an intresting idea and it should also be used for DNS validation because it’s plain annoying having to do stuff manually for a lot of (sub) domians.
I already had suggested this. Because it is “stupid” to change the DNS for the challenge.
- Publish the challenge response via DNS
Better is publish an public key or key fingerprint
- Prove in the challenge that you have access to the public key.
Less json calls, and less modifications to the dns.
- Less updates in the DNS caches.
that’s my opinion and also helps me to work with a lot of SANs. I also want this for http-01.
Here is an example for an DYN-DNS for dynamic IP:
-
cpc2-oldh9-2-0-cust583.10-1.cable.virginm.net
If you would be on the “safe” side you would require:
a) *.cable.virginm.net to be listed on the public suffix list
b) cable.virginm.net blacklist since the subdomains are known to be owned only for short time.
Do you really like to do this ?
So allow IPv4 with DNS challenge would be not more insecure.
@tlussnig have fun doing that dor every provider in the world.
Providers can prevent their customers from getting a certificate for their (dynamic) reverse-lookup-names, by putting a CAA reconrd in DNS - I’m not aware of something similar for IPs.
that is true as well.
I want to add an advantage for public IP certificates.
As I work in SEO, it is recommended to redirect public IP address to the domain name.
Until now, I can redirect http://[IP address] to https://www,example.com, but I can’t redirect from https://[IP address] because the https overrules the server redirect rules and thus the public IP address should be listed in the SAN SSL certificate along with the www and non-www versions of the website.
I hope this can be resolved some day just for the purpose of Search Engine Optimization (SEO).
I think the problem of ownership of IP address is resolved by nature. Suppose some one with DynDNS has a dynamic IP address, why would he issue a certificate for that IP address? once his IP is renewed, his application will be unusable. Is there any (malicious) benefits from issuing a certificate for a dynamic IP address? (suppose that Let’s encrypt allowed it). I don’t know.
@shadi1024 Many, many servers work with SNI based virtual hosts and don’t have a certain single hostname after that single IP address… Your IP->hostname redirect will only work with non-SNI based virtual hosting.
I don’t have the numbers of how many HTTPS servers are IP-based or SNI-based, but I recon the latter is quite common.
There is very little benefit (actually, almost no SEO benefit) in redirecting the IP to a specific domain name, as long as you don't advertise/link the IP. This is mostly a practical benefit, but you don't get any SEO extra-juice with such redirect.
The only benefit you get is to avoid the IP being indexed and accessed by mistake. But as I said, as long as you don't link to it, you're fine. If for some reason it get indexed, you can should consider to 1) add a canonical rel tag in the response and/or 2) setup an empty virtual host that returns a blank response when you access the IP, so that the returned content will not be indexed in place of your website.
The Certificate Authority Browser Forum decided that IP binding with TLS certificates is no longer allowed: https://www.cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf
Also, you would have to actually OWN the IP address, not your ISP, to get verification that a public IP can be binded to a certificate fwiw (typically ISPs lease you IP address, even static ones)
Regardless of principals or right and wrong, to be compliant, letsEncrypt had to disallow this behavior.
1 Like
You are right LE have the right to say NO to IP Addresses.
But the argument that you need to own the IP (Provider Independent Address) is stupid.
You also do not need to own an FQDN. With the same argument you could deny all dyndns names.
But this discussion should if it is worth to discuss should go toi CA/B.
@hackajar, strictly speaking that document only prohibited issuing for a “Reserved IP Address” which refers to RFC 1918 private address space, not for any IP address. I don’t believe there is currently a BR rule that completely forbids issuance for IP addresses, but Let’s Encrypt has decided not to do this.
@tlussnig well the “completely owning” the IP is stupid true, but I think an IP should be checked a bit more clearly than a domain, especially since dynamic IPs exist and there’s no known address space for dyn-IPs.
Where is the difference to dynamic dns provided for these dyn-IPs ?
dnsDNS is a name you (usually) keep for a while but changes IP mapping to whatever you have while you usually keep a dyn-ip just for a day.
small question: can an IP cert also be used for domains served under that IP?
- dyn-dns is also used by providers IP -> XXX.dialin.domain.tld for example
- IP + FQDN + MAIL is all possible in the SAN area and even URL
to 2) no, I mena whether when you have just an IP cert for some IP. would browsers also allow it to be used for domains served under that IP?
about 1) well yeah that also was an argument against allowing seperate sub-domain auth because you could just grab those and the next day you could impersonate that domain even though it is no longer assigned to you. (even though those names are not really used in practice for actually hosting stuff)
- No this is not allowed. If the client support IP based certificate. Than he ONLY check for IP in the cert if the URL does not contain an Hostname.
I give up on this. The argument that you can setup a random domain to map to a IP is enough for me. Actually I remember of the afraid.org, you can pretty much have a free dyn-dns mapper or a static map. So it is pretty easy to get a FQDN for a any IP nowadays.