ed.
> >>>>
> >>>> 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
uld 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
> &
>>>> 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
>>>>
> > > 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
> > 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
hould eliminate
> the race condition, and wouldn't require that a "fake" Static DNS Entry be
> added to a Delivery Service.
>
> From: Derek Gelinas
> Sent: Tuesday, May 7, 2019 6:15 PM
> To: dev@trafficcontrol.apache.
: Derek Gelinas
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'
