You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Fieck, Brennan" <Br...@comcast.com> on 2019/05/08 13:18:57 UTC
Re: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates /
automatic Snapshot
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 <mr...@gmail.com>
Sent: Tuesday, May 7, 2019 6:15 PM
To: dev@trafficcontrol.apache.org
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 <ra...@gmail.com>
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 <mj...@alumni.nd.edu>
> 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
>
Re: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates /
automatic Snapshot
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
I believe the last proposal for significant changes to the CRConfig was https://cwiki.apache.org/confluence/display/TC/Traffic+Control++Self+Service+Proposal+for+Change+Integrity
Jonathan G
On 5/9/19, 8:19 AM, "Steve Malenfant" <sm...@gmail.com> wrote:
Should there be 2 type of CR-Config? A major (all) and minor (less
dangerous things)?
Currently seems like a few things gets propagated if you want it or not.
SSL, Steering and Federation. No CR-Config required.
Steve
On Thu, May 9, 2019 at 10:17 AM Derek Gelinas <mr...@gmail.com> wrote:
> 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 <mj...@alumni.nd.edu>
> wrote:
> >
> > That sounds good to me! Thanks everyone!
> >
> > On Wed, May 8, 2019 at 4:28 PM Chris Lemmons <al...@gmail.com> 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 <sm...@gmail.com>
> >> 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 <
> Brennan_Fieck@comcast.com
> >>>
> >>> 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 <mr...@gmail.com>
> >>>> Sent: Tuesday, May 7, 2019 6:15 PM
> >>>> To: dev@trafficcontrol.apache.org
> >>>> 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 <rawlin.peters@gmail.com
> >
> >>>> 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 <
> >> mjackso8@alumni.nd.edu>
> >>>>> 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
> >>>>>
> >>>>
> >>
>
>
Re: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates /
automatic Snapshot
Posted by Steve Malenfant <sm...@gmail.com>.
Should there be 2 type of CR-Config? A major (all) and minor (less
dangerous things)?
Currently seems like a few things gets propagated if you want it or not.
SSL, Steering and Federation. No CR-Config required.
Steve
On Thu, May 9, 2019 at 10:17 AM Derek Gelinas <mr...@gmail.com> wrote:
> 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 <mj...@alumni.nd.edu>
> wrote:
> >
> > That sounds good to me! Thanks everyone!
> >
> > On Wed, May 8, 2019 at 4:28 PM Chris Lemmons <al...@gmail.com> 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 <sm...@gmail.com>
> >> 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 <
> Brennan_Fieck@comcast.com
> >>>
> >>> 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 <mr...@gmail.com>
> >>>> Sent: Tuesday, May 7, 2019 6:15 PM
> >>>> To: dev@trafficcontrol.apache.org
> >>>> 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 <rawlin.peters@gmail.com
> >
> >>>> 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 <
> >> mjackso8@alumni.nd.edu>
> >>>>> 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
> >>>>>
> >>>>
> >>
>
>
Re: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates /
automatic Snapshot
Posted by Derek Gelinas <mr...@gmail.com>.
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 <mj...@alumni.nd.edu> wrote:
>
> That sounds good to me! Thanks everyone!
>
> On Wed, May 8, 2019 at 4:28 PM Chris Lemmons <al...@gmail.com> 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 <sm...@gmail.com>
>> 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 <Brennan_Fieck@comcast.com
>>>
>>> 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 <mr...@gmail.com>
>>>> Sent: Tuesday, May 7, 2019 6:15 PM
>>>> To: dev@trafficcontrol.apache.org
>>>> 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 <ra...@gmail.com>
>>>> 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 <
>> mjackso8@alumni.nd.edu>
>>>>> 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
>>>>>
>>>>
>>
Re: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates /
automatic Snapshot
Posted by Matthew Jackson <mj...@alumni.nd.edu>.
That sounds good to me! Thanks everyone!
On Wed, May 8, 2019 at 4:28 PM Chris Lemmons <al...@gmail.com> 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 <sm...@gmail.com>
> 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 <Brennan_Fieck@comcast.com
> >
> > 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 <mr...@gmail.com>
> > > Sent: Tuesday, May 7, 2019 6:15 PM
> > > To: dev@trafficcontrol.apache.org
> > > 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 <ra...@gmail.com>
> > > 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 <
> mjackso8@alumni.nd.edu>
> > > > 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
> > > >
> > >
>
Re: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates /
automatic Snapshot
Posted by Chris Lemmons <al...@gmail.com>.
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 <sm...@gmail.com> 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 <Br...@comcast.com>
> 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 <mr...@gmail.com>
> > Sent: Tuesday, May 7, 2019 6:15 PM
> > To: dev@trafficcontrol.apache.org
> > 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 <ra...@gmail.com>
> > 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 <mj...@alumni.nd.edu>
> > > 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
> > >
> >
Re: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates /
automatic Snapshot
Posted by Steve Malenfant <sm...@gmail.com>.
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 <Br...@comcast.com>
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 <mr...@gmail.com>
> Sent: Tuesday, May 7, 2019 6:15 PM
> To: dev@trafficcontrol.apache.org
> 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 <ra...@gmail.com>
> 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 <mj...@alumni.nd.edu>
> > 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
> >
>