There are already topic about that but your forum setting is to autoclose those discussions after 30 days of no reply, yet 3 months is how long your certs are valid.
I’m not happy with your choice of dns only wildcard cert domain validation, and I’m not the only one.
The whole ordeal was thought out very poorly and the one thing that makes LE interesting is the possibility to auto-renew certs.
But with your dns only validation that is not the case.
You are forcing users who want wildcard certificates to few, probably friendly dns providers.
That is backdoor advertising for those providers.
There is no standard in regard to dns manipulation, every dns reseller or provider does it in a different manner. Yet you demand wildcard certs be validated via dns entries.
That doesn’t makes sense and I’m repeating myself other than to advertise those dns providers.
In the past I’ve donated to the EFF. I will never do that again because of how this is handled here and how stubborn you behave in that matter most of all because you are doing this backdoor advertising.
This is not correct…
As a not related to LE person… I can guarantee you that engineers are working their **** out trying to add dns plugins for certbot… however, as you mentioned below
There is no standard in regard to dns manipulation, every dns reseller or provider does it in a different manner
It’s like one thousand DNS providers have two thousand kind of API to use, yet they require different things (might satisfy something to enable API). There are some DNS providers that doesn’t support an API.
Below are my personal thoughts, not related to LE.
In this case, if I’m the engineer among software engineers (especially certbot since you mentioned this), I would put all polular DNS provider on the top of my develop list… since they have more people that might use this service & they normally have good quality (well maintained) API & documentation.
That’s a thing I think most developer would do , support the most populars first, then the other.
Also, since LE’s API endpoints are open to any one who like to develop a software that support this, there are lots of options when choosing clients, and there might be one client that support your DNS provider…
I believe that LE staff member mentioned that they are also developing other methods to validate the domain. But for now, there’s only DNS validation. (At least, from what I think… It’s better to have it rather than not have it. Before LE supports wildcard certificates, you either need to get a certificate with bunch of subdomains or purchase a commercial one, now you get one for Free… Although you’ll need to spend sometime… but that save you lots of money each year)
These are my personal opinion… so let’s call a staff member… they might have a better explanation. @jsha@cpu@schoen
RFC2136, which is implemented by many open source DNS server implementations, and also a number of commercial DNS hosts. Of course, most commercial DNS hosts also don’t want to implement it because then zones would be portable between providers and they’d lose money.
You are not wrong with your whinging. The state of DNS validation is a pain in the ass.
People are trying to improve this exact problem you’re complaining about. assisted-dns was proposed on the IETF ACME list (by a Let’s Encrypt developer, mind you), which would allow for much easier renewals via a permanent delegation of authority to the CA on a domain basis. However, it seemingly received some strong opposition as not confirming to CABF rules.
acme-dns was another approach taken to try to make things easier.
There are also clients like acme.sh and projects like lexicon, totally volunteer-based, that work hard on supporting as many DNS hosts (free and paid) as possible.
It’s good to advocate for change, but you need to do it in the right place and in a positive way. It’s unnecessary to assign bad intent (backdoor advertising) to the way things are.
If you had read any of the threads you mention, you’d know quite well that this isn’t the case. If you hadn’t, well, you really should have. As to the technical reasons for making the decision LE made in this regard, I’ll leave it to those more knowledgeable than I to defend that. But you’re simply, factually, wrong in your repeated claim that this is “backdoor” or any other kind of advertising for any DNS provider, and that only “few” providers are supported.
On the latter point first, as of this moment, acme.sh (just one of the many available clients) supports 48 different DNS providers natively, and others through the use of the lexicon package. That’s a lot, and they include a lot of big names in hosting (OVH and GoDaddy, for example). Some of them are free of cost (Cloudflare, for one).
Further, by spinning up an acme-dns instance, you can issue wildcard (and other) certs using DNS validation with any DNS provider, as long as they’ll allow you to set NS and CNAME records–there’s no need for that provider to support automated updates at all.
But you’re convinced there’s a nefarious reason, and that reason is that LE wants to advertise those “few” services. You’re so convinced of this that you repeat it no less than three times in your post. But think about this for just a moment: if that were the purpose, wouldn’t you expect to see LE actually recommending those services? Because I haven’t, and I looked. I ended up starting my own topic on the question, asking for suggestions.
Challenge DNS-01 is meant to prove full control of a domain, which is why it’s the only implemented method for validating your ownership. Yes, there are some providers which do not offer an API or any other interface to operate programatically with DNS entries, so you either do it manually (once per month per domain) or use SANs like you did in the past.
Can you think of an alternative to checking domain ownership with the same security certainty. Do not forget this system relies on trust.
Hi @dalu! Thanks for your feedback. I’m sorry you’re having a rough time making DNS challenges and wildcard certificates work for you. I agree that they’re hard to get working.
Some of our forum members here have already done an excellent job responding to some of your points, but I’ll repeat a few answers here so you know it’s coming from Let’s Encrypt.
I can assure you that when we made the choice to require DNS validation for wildcards, we did not make that choice based on advertising certain DNS providers. Maybe the point you’re making, though, is that we’re accidentally driving traffic preferentially to DNS providers with well thought out APIs that are easy to use? That’s probably the case, but I think that’s okay.
Here’s a concrete example of why we believe DNS validation is necessary: Many hosting providers give each of their customers a subdomain. For instance, with GitHub Pages I could put any content at jsha.github.io, including a /.well-known/acme-validation/ directory. You could put any content you like at dalu.github.io. Should I be able to do an HTTP-01 validation and get a certificate for *.github.io, which would be valid for dalu.github.io as well? Clearly not.
As @_az pointed out, RFC2136 does provide a standard for DNS manipulation.
Again, thanks for your feedback. This thread is likely to degenerate into a flame war if it goes on much longer, so I’m closing it now. If you’d still like to discuss the topic further, you’re welcome to PM me.