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 my suggestion when discussed on
t; 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] R
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
wrote:
> Putting
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 agree with @mitchell852 , automating snapshots is highly dangerous at the
moment. Even the diff doesn't necessarily catch everything, and even if it
did, there's a race between diffing and snapshotting. DS Snapshots
mitigates the issue, but doesn't solve it entirely.
The right solution is to
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
