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 <[email protected]> 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 <[email protected]> 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 > > >
