Putting the TXT record into the delivery service's static DNS entries does seem like the path of least resistance, but the automatic snapshot requirement could be a little dicey as Jeremy and Rob have described.
Another possible option could be to have TR query a new "out-of-band" TO endpoint (i.e. like the steering and federations endpoints that TR polls periodically for real-time data) that would allow it to get the LetsEncrypt DNS challenges in a real-time manner. Then we wouldn't have to do an automatic snapshot, and whatever TO endpoint you call to make a LetsEncrypt request for a DS would just populate the DB with the challenge, then TR would query all the challenges and update its TXT records appropriately. This all kind of assumes that the integration is mostly in Traffic Ops. Is that along the lines of what you are proposing? What's the end-to-end request/response flow? - Rawlin On Tue, May 7, 2019 at 2:28 PM Matthew Jackson <[email protected]> wrote: > > Hey all, > > I'm working to add integration with LetsEncrypt to get signed certs > automatically for delivery services. In order to prove that I own the > domain, LetsEncrypt does a DNS challenge and requires that a token from > them is put as a TXT record at "_acme-challenge.domain.com". They verify > that the token is there before returning the certs. > > I'm using Traffic Router to do this "DNS" authentication, but this will > require a Snapshot to be taken in order to update TR. LetsEncrypt doesn't > really allow for a break between the request and the challenge, so this > would all have to be done in a row. One option for this would be to add > the TXT record through the "Static DNS Entries" endpoint, automatically > call the Snapshot, and verify the server was updated before returning to > LetsEncrypt. But I wanted to reach out to get everyone's thoughts / other > ideas before proceeding. > > Any thoughts or ideas? > > Thanks > Matt
