I would like LE to target a bit neglected part of auditory here.
I have multiple hosts covered with SSL certs from regular authorities like Comodo, both on public and private networks. I’m comfortable with the idea of replacing them with LE issued ones and automating whole process.
I’m not comfortable however with letting 3rd party utilities mess with my webserver configs or putting private servers on public networks for a brief periods of time like suggested in other threads.
If my understanding is correct ACME protocol allows for verification via adding new DNS record with the control string. Why is this not a priority for the first release? It’s the simplest check of all (or on par with simple HTTP check).
I’m aware of that, but this is out of the scope of this question and not LE’s concern. DNS providers with automation tools available out of the box are not limited by those two examples.
I would go as far as drop automation aspect of this question altogether in favor of publicly inaccessible servers — there is no good solution except DNS checks, automatic or not.
I’ve mentioned this in other places before too, but DNS validation also allows for a way easier automation workflow for deployment environments where modifying TLS termination endpoints is not feasible (e.g. Amazon ELBs) or where offering special content a well-known URI at the authorizing domain is challenging (e.g. Heroku or Cloud Foundry).
For many individual developers and small shops, which I think are a big part of Let’s Encrypt’s target audience, application hosting is moving away from hand-managing servers with command line tools.
Yeah, that does look promising… Definitely hope to see this in place as it will enable me to easily set up a gateway server that all of my internal developers can use to request certificates for hidden/on-premise servers - without those servers being made available for external connections.
I work for a registrar and we manage many customers DNS from our Nameservers, adding a TXT record is the most straightforward form of validation for us.
A CA may choose different sets of challenges depending on whether it has interacted with a domain before, and how. For example:
New domain with no known certificates: Domain Validation (DVSNI or Simple HTTP)
are there any reasons other than what @riking has provided in this thread for not doing DNS validation via TXT record the first time the CA sees a new domain name?
Mainly this, we'd rather be much more confident with our original challenge types and the rest of the issuancce infrastructure than rushing to add a new feature (and fixing all the bugs that come along with that process).
Do you have a rough idea of what additional development will be required? Is this something where significant work has to be done, or are there just a few small missing pieces? Main reason I ask is that supporting pure-DNS validation opens up a whole range of use cases for LetsEncrypt certificates for internal servers that couldn’t ever reasonably be made directly accessible - but their names could trivially be made visible to public dns.
Obviously this is isn’t the primary use case - but I think you’ll find that there will be large numbers of people that would make use of these certificates for internal services that wouldn’t otherwise be able to use them - for internal test servers, networking infrastructure, management endpoints, etc.
In my case, I’d set up a special intermediate server that internal authenticated users could use - and would have that server perform all the interactions with LE, including updating DNS for validations.
@nneul: Much of the code has been written, but we are really sharpening our focus to make sure we hit our launch dates with the very best code, which is why we’re not launching with support for DNS-based challenges. We agree it’s extremely useful, especially for hosting providers, and are going to try and launch it sometime not long after launch of the overall service.
@jsha Suggestion to consider that would be much simpler - and much narrower code path change - but would allow for the same level of functionality for hosting providers/private networks/etc as DNS based validation:
Keep using the Simple HTTP based validation, but instead of JUST connecting to IP(domain), add the capability to do a SRV record lookup to determine the ip/hostname to connect to.
i.e.
_letsencrypt-acme-http.<domain>. IN SRV 10 2 80 my-acme-dmz-host.my.same.or.other.domain.
_letsencrypt-acme-https.<domain>. IN SRV 10 2 443 my-acme-dmz-host.my.same.or.other.domain.
That would allow for the scenarios of having a dmz or alternate host to manage the acme enrollment - but still in a mostly automated fashion. Would also allow for the scenarios that many have brought up for cases where they can’t run the ACME software on the actual host - such as when there is a cluster of servers hosting the domain - or for users that have AWS/CloudFront/etc. sitting in front making it more difficult to do the fully automated request.
To me, this would require only very minimal changes to the validation code - to do the additional optional DNS lookup to control what host is connected to for the validation. The rest of the Simple HTTP validation logic could stay exactly the same.
A slight variation of this would be:
_letsencrypt-acme-proxy.<domain>. IN SRV 10 2 80 my-acme-dmz-host.my.same.or.other.domain.
which would be a bit more complicated to implement - since you’d have to be aware of proxy protocol/CONNECT/etc. depending on what URLs you passed through.
Not to repeat what others have said, but similar to konklone’s point, this would make appengine and other such services easy, whereas right now manual method involves major edits to static file serving configs.
if we ycould get the ability to change the port using that SRV I am all into it, I could tell it to use some port I dont really use and then forward that to my raspi. while my PC doesnt care at all about anything
It seems that the dns-01 challenge is currently not offered by the server running at: acme-v01.api.letsencrypt.org even though the implementation is already in boulder. Is there already a timeline for when this authorization method will be available?
What is not exactly clear is whether the authorization of a domain through a dns-01 challenge does imply the authorization of all hosts (excluding sub domains) under this domain, possibly even for host names which do not (yet) have a DNS record?
