For example if I am on dialup on the “example” ISP, I can get a certificate for dialup123.example.com even though example.com is owned by my ISP and he hasn’t given me permission.
I think there needs to be a way for domain owners to prevent this. Perhaps it could be done in DNS using a TXT record?
For domains with such a TXT record there would have to be an additional check, for example using the contact data given in WHOIS or using the domain name without any subdomains/hostname before a certificate is issued.
What do you think? I’m sure this issue has already been considered?
Well, for many ISPs you only own dialup123.example.com for 24 hours, after that some other customer gets it. Yet the certificate is valid for much longer.
Should you really get a certificate for that hostname? What if the other customer also wants to get a certificate for the same hostname, just 24 hours later? Also, consider what happens when 10.000 customers of the ISP want to get a certificate for example.com subdomains. They can’t because of the per domain limits that Let’s Encrypt imposes. So it’s “first come, first serve”? That doesn’t seem like a good solution.
I think you should be using dynamic DNS with a domain you own and get a certificate for that domain instead.
@Nemis Sorry but you are wrong you do not “own” dialup123.example.com it is only temporary assigned to you.
So the question from Sid is even wrong. Not the domain owner need to forbid the creation of CA’s the domain owner should grant the permission for subdomains.
Lets take another practical example. If you rent a car. You can drive the car, wash the car and show the car to friends.
Depended on the contract you are allowed to let third people drive the car. But you can not sell the car. The car owner must not say to anybody he is not allowed to sell. he only does not give the permission (fahrzeug brief). And if you buy the car you can get also punished because you did not check if this is his car.
For LE this would imply either via DNS or main domain the domain owner have to grant the creation of sub domain certificates.
Hi, this is not only an Problem with dynamic IP.
This problem is also with Servers that allow per user FQDN’s.
Or even more worse in the case of allowing verification via non default port.
Since each user on an Host can open high ports, it is possible to open an port >1024 and then get certificates for any domain under this ip.
So the question from Sid is even wrong. Not the domain owner need to
forbid the creation of CA's the domain owner should grant the
permission for subdomains.
Instead of blocking subdomains (blacklist) for automatic certificates from CAs like Let's Encrypt, the domain owner could be granting permission (whitelist). That's just a detail that is to be figured out.
well how secuer are the whois records? an Idea would be an initial check to the whois email and/or the administrative emails of that domain, and keep the auth until the whois data changes some important points.
This is not an small detail it is an very important point. Since you can not require that each domain owner knows each CA rules and block any one individually, the only option if we think about it is whitelisting. Because than the owner is only required to do something if he want an cert.
To keep the car example: No one would say an rental service need to forbid buying his cars to each dealer individually.
@My1 instead of introducing a new method of authentication (using email from unauthenticated WHOIS records), I think the better alternative is to optionally require a second ACME check on the server of the domain itself, i.e. example.com
So we would have two checks if the domain owner indicates that he doesn’t want unauthorized certificates (blacklist) or does not approve of such certificates (whitelist):
on dialup123.example.com
on example.com
Only if both checks succeed the certificate is granted.
well most CAs dont do HTTP check but checks against DNS or whois/admin email, and I dont know whether they all deal with CAs.
also if they give out sub domains to users so those can use them, where is the problem of the users getting a cert for that domain?
getting a cert and selling a car are dome really different things, and at least I think that the only thing checks that you in some way have control over the (sub) domain, so I see no problem there since the cert is just for the sub anyway.
@My1 the problem begin with the lifetime even 90 days are long for example for an Dial-In domain.
And since the browser highlight only domain for example on this page only letsencrypt.org is black
whilte community. and path is gray this could be also used together with IDN for misuses.
For example “SUPP0RT.dyndns.org” the user see in black dyndns.org the Lock Sign is green
and the hostname let him think it is the official support page.
well okay year THERE the problem starts but the only one who have those are ISPs and they should be mighty enough to blacklist it.
or are there any lists of the “dynamic domains” of ISPs?
but why do ppl get a “dynamic domain” in the first place?
I think, conceptually, handing over full control of a subdomain to a user should mean the user is free to use the domain as they wish - including getting signed certificates.
For the vast majority of user-generated domains, the short certificate lifetime should suffice in preventing any abuse. For the rest, I would argue that a way for domain-owners to opt-out (as opposed to opt-in) that is not limited to Let’s Encrypt would be preferable, since it only affects a relatively small number of domains. I believe Let’s Encrypt checks DNS CAA records which allow you to specify which CAs are allowed to issue certificates for any domain. This would allow ISPs with dynamic IPs to prevent Let’s Encrypt from issuing certificates for their domains.
I think it is a good thing that LE doesn't treat subdomains any different. Who uses those clunky short lived 1.2.3.4.dynamic.example.net domains for something serious anyway? This sounds very much like a theoretical problem which is a non issue in practice.
As discussed in that other thread, this is as it should be for a DV cert. It is the job of dyndns.org to not assign such a subdomain in the first place (and the job of the browser vendors to design their UI accordingly).
Sure shorter lifetimes ease those ownership change problems but also have their shortcomings.