If adding "static entries" is less or non disruptive. Probably having another endpoint that doesn't require CR-Config could be acceptable. Like steering and others.
I'm assuming we are only talking about the DNS challenge so far and nothing about updating the certs themselves. Looks like TR handles this automatically so far, but not the edge caches... Steve On Wed, May 8, 2019 at 9:19 AM Fieck, Brennan <[email protected]> wrote: > Yeah, automatic snapping is risky. I'm +1 on implementing IMS, though. I'm > not sure it'll be as > easy as Rob thinks - well, `/snapshot` would be, but I think > `/snapshot/new` will be significantly > more involved. > > As far as ACME challenges go, we could build a client into TR, so that the > endpoint for TO actually > just acts as a gateway and requests that TR handle certificate/key > generation. That should eliminate > the race condition, and wouldn't require that a "fake" Static DNS Entry be > added to a Delivery Service. > ________________________________________ > From: Derek Gelinas <[email protected]> > Sent: Tuesday, May 7, 2019 6:15 PM > To: [email protected] > Subject: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates / > automatic Snapshot > > This was my suggestion when discussed on slack earlier as well. Probably > the easiest to implement though I think Rob's suggestion also had merit. > I'm -1 on anything that auto snaps, and LE can't really wait around for a > user snap. > > On Tue, May 7, 2019 at 7:29 PM Rawlin Peters <[email protected]> > wrote: > > > 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 > > >
