I agree with this for this implementation, but I find myself wondering if there's anything else that might be detached from the primary crconfig in order to help automate things/separate them from more dangerous activities, like disconnecting servers from services or setting them offline, that sort of thing.
Thoughts on that? I can start a new thread if desired since this is somewhat out of the scope of the original conversation. Derek > On May 9, 2019, at 9:47 AM, Matthew Jackson <[email protected]> wrote: > > That sounds good to me! Thanks everyone! > > On Wed, May 8, 2019 at 4:28 PM Chris Lemmons <[email protected]> wrote: > >> I think the out-of-band solution might be the cleanest and safest. >> It's a bit more work, but it keeps things separate that should be >> separate. Additionally, it significantly reduces the risk that an >> error in the ACME logic causes trouble for unrelated DSs. >> >> On Wed, May 8, 2019 at 9:00 AM Steve Malenfant <[email protected]> >> wrote: >>> >>> 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 >>>>> >>>> >>
