Would it be reasonably safe to say that if you’re a standard ISP customer with a DHCP address and a hostname you don’t own cause it would constantly change, that they’re likely blocking inbound 80/443 so you couldn’t answer the challenge and thus couldn’t prove you own the domain anyway? at least in some cases / ISP’s…
well at least at my cable internet and my DSL the ports were open from the ISP side. I just needed to setup portforwarding and it works, I still so that.
Let's Encrypt supports the CAA (Certificate Authority Authorization) standard, which allows domain owners to specify which CAs are allowed or disallowed to issue certificates on their domains.
8 Likes
Hi nice to hear about CAA record.
But for example PowerDNS does not support http://comments.gmane.org/gmane.network.dns.powerdns.user/11598
And i think most of the domain owners will first hear of this option after there was an problem.
Can this be solved by the example.com owner pointing 1.2.3.4.example.com or whatever.example.com or SUPP0RT.dyndns.org to one of his/her servers and on that server runs Let’s Encrypt to revoke all certs previously issued for that subdomain?
So, as long as you control dialup123.example.com, then it seems reasonable to me that you can get a cert for it. And if example.com doesn’t like that, they take back dialup123 and destroy (revoke) your cert. (?)
To revoke it, you would have to know that there is a cert at all and who issued it.
well the exstense of the cert shouldnt be hard to find, LE has CT.
but the problem is if somebody makes a cert everytime he gets a new ISP-domain (should happen every day or more often if router reconnects and gets a new IP) and well then the ISP would have to revoke a cert each day, and that would be quite a long CRL if multiple people do that.
[quote=“My1, post:27, topic:4205, full:true”]if somebody makes a cert everytime he gets a new ISP-domain
[/quote]
why somebody want to do this? an ssl at every new reconnection/dinamic ip?
go for selfigned cert and trust it, as the same way a lot of embedded device expose it web gui
well why would want is not the question. with the current LE-model it is possible and there needs to be a way for ISPs to say that a subdomain cannot get a cert.
also LE is automated and free so it’s not just possible but it is not even hard.
also a trusted cert is always better…
no. ssl for reverse dns can be usefull
how, just get a DynDNS and you have your domain, and getting a cert on each recon will be certainly a strain on the cert and OCSP server
as well as the global ratelimit.
Actually I think so few people would ask for a new cert each day, so it wouldn't be a problem. I would guess other "normal" cert usage is X*90 times more frequent (where X is fairly large and 90 is the max days a cert is valid). So I would think normal cert usage would dwarf one-day cert usage, and that the problem you mention doesn't exist (in real life).
I'm planning to build forum software that runs on subdomains, encrypted with Let's Encrypt. Therefore, someone being able to block subdomains from obtaining a cert, would result in these subdomains not getting encrypted. No HTTPS. So from my point of view, someone being able to block a domain's subdomains from getting a cert, is bad.
Anyway if this too-many-certs-to-subdomains turns out to be a real problem, not just a theoretical one, can it not then be quickly solved by rate limiting certs per domain. Max 100 certs per domain (incl subdomains) and day, say. And rate limiting per subdomain. And rate limiting per organization that asks for certs and per IP (and perhaps something more). I'd guess that LE does this already. And that the too-many-certs problem you have in mind thus has been solved already.
I dont say that subdomains should be blocked but that isps should be able to block their own subs from le (free dyndns stuff is running everywhere, so you also can get a better working sub there.)
And
1 Like
Already possible (if your dns support it) via CAA DNS-Record.
1 Like
FIXED for this no-sense tread.
@Nemis no, then I couldnt be able to host my stuff at home over default ports, which is plain annoying.
Why should the owner (or registrant? or zone master?) of “example.com” be allowed to forbid the use of encryption for you? By recursion, this would also require a permission to encrypt from the owner of “com” - and then of the owner of the root domain!
The purpose and extent of the level of valuation as performed by LE (and others) is not to verify that you have control over the DNS entry dialup123.example.com (as in: can arrange to have it point to another IP), rather it is to verify that you have sufficient control over the host reachable under that hostname (as in: can arrange for arbitrary content being served under port 443).
On the other hand, the owner of example.com has a very simple way to prevent being falsely associated with certs issued to your dialup host: They might just remove the forward DNS entry dialup123.example.com … (With a volatile dialup connection you won’t need a forward entry, at least not one related to example.com, and might want to setup something with your own domain via dyndns)
Incidentally, services like startssl would require control over example.com (as in: receive mail for hostmaster@example.com) in order to obtain a cert for dialup123.example.com; but then again this is not really a difference insofar as their cert would be valid for both “dialup123.example.com” and “example.com”.
Why should the owner (or registrant? or zone master?) of "example.com" be allowed to forbid the use of encryption for you?
@hagman If you can't use someone elses domain name that doesn't mean you can't use encryption whatsoever. You can always use your own domain name or a domain name where the owner gives you permission.
Getting a certificate for a hostname makes it look more official, you could argue that it makes it easier to impersonate the domain owner, especially for dynamic DNS service (what if I pick something like customerservice.dyndns.org and start impersonating DynDNS...?)
And yes the fact that other CAs require ownership of one of the email addresses from the WHOIS data is exactly what this thread is about.
That is not universally correct, other CAs provide alternative verification mechanisms like DNS and HTTP as well. WoSign comes to mind as an example.
I think we've already established that there are solutions for domain owners who wish to prevent this from happening (namely CAA records). If your DNS provider doesn't allow you to make use of that, that's not something you can blame Let's Encrypt for. Considering that there are other CAs who allow similar verification mechanisms, using an established, standardized way of preventing CAs from issuing such certificates should be preferred to either introducing yet another mechanism that is vendor-specific or introducing some kind of LE-specific blacklist.
2 Likes
Agreed.
However, I guess there is a difference between the cases of (temporary but provided by access provider) dialup123.example.com and (somewhat permanent from an access-independent contract) customerservice.dyndns.org or maybe to carry that further www.microsotf.com (note the spelling). In fact, the latter two might already be confusing with http. Maybe this discussion is more about the distiction of DV cert vs. EV cert and less about http vs. https.