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 email@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.
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.
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.)
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 EV certificate, which aren’t allowed to include wildcards)
manager.linode.com (the same EV certificate;
manager.linode.com is included in
*.linode.com wildcard certificate)
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.