Having a DV cert shouldn't increase any trust, but it does. It's the browsers' fault and an educational issue.
also since firefox made the locks green for all certs thereâs no first sight difference between DV/OV and EV (green vs grey lock) on Firefox mobile because the name isnt shown because of space.
Then report it as bug / feature request. 
The topic is: Certs for subdomains without the domain ownerâs permission.
Dialup access is one area, dynamic DNS services is another area where this is of relevance.
If you are granted a certificate for a dialup number you can MITM that address for 90 days even if the address has a new owner.
If you are granted a certificate for a dyndns domain name, you can try to abuse it in other ways. Or perhaps the domain owner is OK with it. The question remains: Shouldnât it be up to the domain owner to decide?
You could do that for 1 year, not only 90 days. But who is actually MitM dialup addresses and using and / or trusting them?
For DynDNS it's absolutely right that you can get a certificate IMO.
Some CAâs has HTTP validation steps alongside with DNS validation steps, I know one (that popular nowadays) and a reseller. I am pretty sure I can get 1 year (or more) certificate for the domains mentioned above.
As long as the domainâs A record points to you and you provide the challenge, there is nothing preventing you to get the certificate since you protect the data that points to you.
From earlier posts, one mentioned expiration date of the certificate should not exceed the domain expire time. However, this does not protect people to buy domains (for 3 years) and certificates (3 years) for them and sell them thought. I think it is the same issue weâre talking here, in both cases one owns a certificate for the domain he/she does not own anymore, therefore LE must be able issue certificates to the domains mentioned earlier. I think this is where the advantages of certificate revocation and 90 day lifetime of certificates come in.
CAâs (including LE) already uses public suffix lists to prevent com.tr owner to get *.com.tr certificates for example. (I know LE does not issue wildcard certificates, but I mean other CAâs)
Youâre right this issue is linked to DV certificates and is not LE-specific.
You do not purchase the certificate for the dial-up number itself but for yourself. The caller looks your name in address book (like DNS system) and finds your dial-up number then calls you, then you provide valid certificate for your name in the address book not the dial-up number, and the caller verifies the name he/she wants to call on the certificate not the dial-up number the dialer dials.
I think there are a lot of places where defaulting subdomains to whitelist makes sense, even to the TLD owner. One example is an application like Zendesk, where each customer gets something like support.customerdomain.com. I had to manually go through and upload an SSL certificate to Zendesk in order to support support.customerdomain.com.
Iâd much rather give my implicit permission to Zendesk to use Lets Encrypt (or something similiar) to get their own certificate on my behalf than to involve me in this process at all. In fact, Iâm giving them the explicit permission by setting up the A or CNAME record.
On the flip side, I run a business where I setup e-commerce shops on subdomains for customers that often are not very technical. Involving them in anything more than pointing the subdomain is a huge barrier to entry and a large timewaster for all involved.
It seems to me, like pointed out, in the case of an ISP the ISP has the ability to do something proactive to restrict subdomain SSL certificates â in all other cases, âLetâs Encryptâ!
But what if the main (non-sub) domain has a cert that doesnât allow for subdomain certs? Is that possible?
No, that's not possible. The existence of one certificate cannot prevent other certificates from being created. It's just not how the system works.
(Well, a certain CA's internal policies might. For example, Let's Encrypt's rate limits, or StartSSL's thing about refusing to issue duplicate certificates at all. But that doesn't stop you from using a different CA.)
The CAA DNS record mentioned above is the only way i know of to stop certificate issuance. And Let's Encrypt checks it, but most CAs don't.
Should the ISPs stop giving itâs clients sub domains it doesnât want others to control, and start using sub.ispclients.tld ?
I donât see any real life problem here, other than ISPs bad practices (same old story).
Iâve seen certsâ common-names with wildcards like â*.asite.comâ. But I suppose that only applies to the particular cert and canât override whatever subdomain certs there may be.
Right. If you're using a wildcard certificate for some subdomains, it doesn't stop you from using different certificates for other subdomains, if you want to (and your software supports it, or they're being hosted on different servers).
Here's an example:
www.linode.com (www.linode.com EV certificate, which aren't allowed to include wildcards)
manager.linode.com (the same EV certificate; manager.linode.com is included in subjectAltName)
blog.linode.com (*.linode.com wildcard certificate)
status.linode.com (status.linode.com included in subjectAltName; the subdomain is hosted by StatusPage.io and the certificate covers dozens of their clients)
It seems that Linode decided to fork out for an EV certificate for their most critical subdomains, and use a less expensive wildcard certificate for their less important subdomains. Plus one of their subdomains is hosted by a third party service, with a certificate generated by the third party that only covers that subdomain.