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
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.
On Tue, Feb 13, 2018 at 12:14 PM, Nir Sopher <n...@qwilt.com> wrote:
> 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
> See issue 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
> 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.