You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Rawlin Peters <ra...@gmail.com> on 2018/09/21 16:06:08 UTC
Delivery Service SSL key versioning
Hey Traffic Controllers,
So while working on the TO Go DS sslkeys endpoints [1], I found that
we lost a feature in the transition from the old TO Perl UI to the
Perl API, and since the since the TO golang is basically just a
rewrite of the Perl endpoints, this feature of the Perl UI was
overlooked so far in the rewrite.
This feature is delivery service SSL key versioning, where adding new
SSL keys to a delivery service would increment the version of
deliveryservice.ssl_key_version and store the new keys in Riak using
the incremented version (as well as store them as the 'latest'
version). This means that all the previous ssl keys of the DS are
stored in Riak and saved indefinitely, so if need be you can always
get to the previous ssl keys of the DS.
This feature was somehow left out of the Perl API implementation, so
currently the API is just overwriting the 'latest' (and whatever the
existing ssl_key_version of the DS is) keys whenever you add new ssl
keys to the delivery service. Since ssl_key_version isn't incremented,
this means you can no longer retrieve your previous ssl keys for a DS
once you've added new ones.
My hunch is that this wasn't done on purpose, but I can't confirm
since the Perl API predates me. We would still want that functionality
in the API, right? I've opened a GitHub issue [2] to track this.
- Rawlin
[1] https://github.com/apache/trafficcontrol/pull/2853
[2] https://github.com/apache/trafficcontrol/issues/2855
Re: [EXTERNAL] Re: Delivery Service SSL key versioning
Posted by Rawlin Peters <ra...@gmail.com>.
Alright, I'll definitely get the ssl key versioning into the Go API then.
@andrew TR just hits the API to get all the SSL keys for the CDN, but
that CDN SSL keys API hits Riak and gets all the ssl keys with the
'latest' version (i.e. that literal string). In Riak the ssl keys are
stored using the key <xml_id>-<version>, so there should always be a
key for "myds-latest" for instance, which is the latest ssl key for
"myds". But with ssl key versioning there should also be "myds-0" and
"myds-1", for instance if two sets of keys had been added to "myds",
where "myds-1" and "myds-latest" both point to the same sets of ssl
keys. If another set of ssl keys is added to that DS, they would get
stored in Riak under the key "myds-2", and "myds-latest" would be
overwritten to the same ssl keys.
On Fri, Sep 21, 2018 at 12:04 PM Gelinas, Derek
<De...@comcast.com> wrote:
>
> +1 on that. We definitely want to keep that in place.
>
> On 9/21/18, 1:38 PM, "Dave Neuman" <ne...@apache.org> wrote:
>
> Yes we need to keep it. This functionality has saved us on more than one
> occasion.
>
>
> On Fri, Sep 21, 2018 at 10:06 AM Rawlin Peters <ra...@gmail.com>
> wrote:
>
> > Hey Traffic Controllers,
> >
> > So while working on the TO Go DS sslkeys endpoints [1], I found that
> > we lost a feature in the transition from the old TO Perl UI to the
> > Perl API, and since the since the TO golang is basically just a
> > rewrite of the Perl endpoints, this feature of the Perl UI was
> > overlooked so far in the rewrite.
> >
> > This feature is delivery service SSL key versioning, where adding new
> > SSL keys to a delivery service would increment the version of
> > deliveryservice.ssl_key_version and store the new keys in Riak using
> > the incremented version (as well as store them as the 'latest'
> > version). This means that all the previous ssl keys of the DS are
> > stored in Riak and saved indefinitely, so if need be you can always
> > get to the previous ssl keys of the DS.
> >
> > This feature was somehow left out of the Perl API implementation, so
> > currently the API is just overwriting the 'latest' (and whatever the
> > existing ssl_key_version of the DS is) keys whenever you add new ssl
> > keys to the delivery service. Since ssl_key_version isn't incremented,
> > this means you can no longer retrieve your previous ssl keys for a DS
> > once you've added new ones.
> >
> > My hunch is that this wasn't done on purpose, but I can't confirm
> > since the Perl API predates me. We would still want that functionality
> > in the API, right? I've opened a GitHub issue [2] to track this.
> >
> > - Rawlin
> >
> > [1] https://github.com/apache/trafficcontrol/pull/2853
> > [2] https://github.com/apache/trafficcontrol/issues/2855
> >
>
>
Re: [EXTERNAL] Re: Delivery Service SSL key versioning
Posted by "Gelinas, Derek" <De...@comcast.com>.
+1 on that. We definitely want to keep that in place.
On 9/21/18, 1:38 PM, "Dave Neuman" <ne...@apache.org> wrote:
Yes we need to keep it. This functionality has saved us on more than one
occasion.
On Fri, Sep 21, 2018 at 10:06 AM Rawlin Peters <ra...@gmail.com>
wrote:
> Hey Traffic Controllers,
>
> So while working on the TO Go DS sslkeys endpoints [1], I found that
> we lost a feature in the transition from the old TO Perl UI to the
> Perl API, and since the since the TO golang is basically just a
> rewrite of the Perl endpoints, this feature of the Perl UI was
> overlooked so far in the rewrite.
>
> This feature is delivery service SSL key versioning, where adding new
> SSL keys to a delivery service would increment the version of
> deliveryservice.ssl_key_version and store the new keys in Riak using
> the incremented version (as well as store them as the 'latest'
> version). This means that all the previous ssl keys of the DS are
> stored in Riak and saved indefinitely, so if need be you can always
> get to the previous ssl keys of the DS.
>
> This feature was somehow left out of the Perl API implementation, so
> currently the API is just overwriting the 'latest' (and whatever the
> existing ssl_key_version of the DS is) keys whenever you add new ssl
> keys to the delivery service. Since ssl_key_version isn't incremented,
> this means you can no longer retrieve your previous ssl keys for a DS
> once you've added new ones.
>
> My hunch is that this wasn't done on purpose, but I can't confirm
> since the Perl API predates me. We would still want that functionality
> in the API, right? I've opened a GitHub issue [2] to track this.
>
> - Rawlin
>
> [1] https://github.com/apache/trafficcontrol/pull/2853
> [2] https://github.com/apache/trafficcontrol/issues/2855
>
Re: [EXTERNAL] Re: Delivery Service SSL key versioning
Posted by Jeremy Mitchell <mi...@gmail.com>.
99% sure not done on purpose. good catch.
On Fri, Sep 21, 2018 at 11:55 AM Schmidt, Andrew (Contractor) <
Andrew_Schmidt@comcast.com> wrote:
> Where is this being used? Traffic Router is definitely not examining the
> version when it pulls the keys.
>
>
> On 9/21/18, 11:38 AM, "Dave Neuman" <ne...@apache.org> wrote:
>
> Yes we need to keep it. This functionality has saved us on more than
> one
> occasion.
>
>
> On Fri, Sep 21, 2018 at 10:06 AM Rawlin Peters <
> rawlin.peters@gmail.com>
> wrote:
>
> > Hey Traffic Controllers,
> >
> > So while working on the TO Go DS sslkeys endpoints [1], I found that
> > we lost a feature in the transition from the old TO Perl UI to the
> > Perl API, and since the since the TO golang is basically just a
> > rewrite of the Perl endpoints, this feature of the Perl UI was
> > overlooked so far in the rewrite.
> >
> > This feature is delivery service SSL key versioning, where adding new
> > SSL keys to a delivery service would increment the version of
> > deliveryservice.ssl_key_version and store the new keys in Riak using
> > the incremented version (as well as store them as the 'latest'
> > version). This means that all the previous ssl keys of the DS are
> > stored in Riak and saved indefinitely, so if need be you can always
> > get to the previous ssl keys of the DS.
> >
> > This feature was somehow left out of the Perl API implementation, so
> > currently the API is just overwriting the 'latest' (and whatever the
> > existing ssl_key_version of the DS is) keys whenever you add new ssl
> > keys to the delivery service. Since ssl_key_version isn't
> incremented,
> > this means you can no longer retrieve your previous ssl keys for a DS
> > once you've added new ones.
> >
> > My hunch is that this wasn't done on purpose, but I can't confirm
> > since the Perl API predates me. We would still want that
> functionality
> > in the API, right? I've opened a GitHub issue [2] to track this.
> >
> > - Rawlin
> >
> > [1] https://github.com/apache/trafficcontrol/pull/2853
> > [2] https://github.com/apache/trafficcontrol/issues/2855
> >
>
>
>
Re: [EXTERNAL] Re: Delivery Service SSL key versioning
Posted by "Schmidt, Andrew (Contractor)" <An...@comcast.com>.
Where is this being used? Traffic Router is definitely not examining the version when it pulls the keys.
On 9/21/18, 11:38 AM, "Dave Neuman" <ne...@apache.org> wrote:
Yes we need to keep it. This functionality has saved us on more than one
occasion.
On Fri, Sep 21, 2018 at 10:06 AM Rawlin Peters <ra...@gmail.com>
wrote:
> Hey Traffic Controllers,
>
> So while working on the TO Go DS sslkeys endpoints [1], I found that
> we lost a feature in the transition from the old TO Perl UI to the
> Perl API, and since the since the TO golang is basically just a
> rewrite of the Perl endpoints, this feature of the Perl UI was
> overlooked so far in the rewrite.
>
> This feature is delivery service SSL key versioning, where adding new
> SSL keys to a delivery service would increment the version of
> deliveryservice.ssl_key_version and store the new keys in Riak using
> the incremented version (as well as store them as the 'latest'
> version). This means that all the previous ssl keys of the DS are
> stored in Riak and saved indefinitely, so if need be you can always
> get to the previous ssl keys of the DS.
>
> This feature was somehow left out of the Perl API implementation, so
> currently the API is just overwriting the 'latest' (and whatever the
> existing ssl_key_version of the DS is) keys whenever you add new ssl
> keys to the delivery service. Since ssl_key_version isn't incremented,
> this means you can no longer retrieve your previous ssl keys for a DS
> once you've added new ones.
>
> My hunch is that this wasn't done on purpose, but I can't confirm
> since the Perl API predates me. We would still want that functionality
> in the API, right? I've opened a GitHub issue [2] to track this.
>
> - Rawlin
>
> [1] https://github.com/apache/trafficcontrol/pull/2853
> [2] https://github.com/apache/trafficcontrol/issues/2855
>
Re: Delivery Service SSL key versioning
Posted by Dave Neuman <ne...@apache.org>.
Yes we need to keep it. This functionality has saved us on more than one
occasion.
On Fri, Sep 21, 2018 at 10:06 AM Rawlin Peters <ra...@gmail.com>
wrote:
> Hey Traffic Controllers,
>
> So while working on the TO Go DS sslkeys endpoints [1], I found that
> we lost a feature in the transition from the old TO Perl UI to the
> Perl API, and since the since the TO golang is basically just a
> rewrite of the Perl endpoints, this feature of the Perl UI was
> overlooked so far in the rewrite.
>
> This feature is delivery service SSL key versioning, where adding new
> SSL keys to a delivery service would increment the version of
> deliveryservice.ssl_key_version and store the new keys in Riak using
> the incremented version (as well as store them as the 'latest'
> version). This means that all the previous ssl keys of the DS are
> stored in Riak and saved indefinitely, so if need be you can always
> get to the previous ssl keys of the DS.
>
> This feature was somehow left out of the Perl API implementation, so
> currently the API is just overwriting the 'latest' (and whatever the
> existing ssl_key_version of the DS is) keys whenever you add new ssl
> keys to the delivery service. Since ssl_key_version isn't incremented,
> this means you can no longer retrieve your previous ssl keys for a DS
> once you've added new ones.
>
> My hunch is that this wasn't done on purpose, but I can't confirm
> since the Perl API predates me. We would still want that functionality
> in the API, right? I've opened a GitHub issue [2] to track this.
>
> - Rawlin
>
> [1] https://github.com/apache/trafficcontrol/pull/2853
> [2] https://github.com/apache/trafficcontrol/issues/2855
>