Would deleting the certificate only remove the "latest" copy/alias? The
certificate and keys should still be retrievable manually.  Yes/No?

On Tue, Feb 13, 2018 at 5:40 PM, Dave Neuman <neu...@apache.org> wrote:

> I think I can get on board with not allowing a user to change the CDN.  If
> you want to change the CDN you need to delete your DS and re-create it or
> create a new DS with a different XML_ID and a regex that matches the first
> DS.
>
> We have gone back and forth several times on deleting the keys from riak
> when you delete a DS.  Each time we decide not to make the change for one
> reason or another.  The worry is that if you delete a DS and then decide
> that it was a mistake you now have to generate a whole new certificate
> which could cost real money.  I am not sure that use-case is common enough
> to warrant us not deleting the certificates for a DS.  For now I am +1 on
> deleting the certificates when a DS is deleted.
>
> Thanks,
> Dave
>
> On Tue, Feb 13, 2018 at 12:14 PM, Nir Sopher <n...@qwilt.com> wrote:
>
> >  Hi,
> >
> > I created a delivery service and later on realized it is in the wrong
> CDN.
> > I then changed the CDN.
> > The ssl-keys record in the riak kept referring to the old CDN, even if I
> > generated new certificates. Traffic router was therefore unable to pull
> the
> > certificate.
> >
> > See issue 1847
> > <https://github.com/apache/incubator-trafficcontrol/issues/1847>
> >
> > A fix to this issue can be done by changing the code so the record in the
> > Riak is updated along with the DS update.
> > However, this does not really make sense - if the CDN has changed, the
> > domain usually changes as well and the certificate is no longer valid.
> >
> > Therefore, I suggest to entirely block DS CDN change [see
> > https://github.com/apache/incubator-trafficcontrol/pull/1872]
> > .
> > Additionally, I added a PR for ssl-keys deletion up-on DS deletion, so
> > deleting the DS and recreating it would not cause similar issues.
> >
> > Would appreciate community input for other alternatives.
> >
> > Thanks,
> > Nir
> >
>

Reply via email to