https support for http delivery services

[Trevor Ackerman]

We've made good progress on supporting https for http delivery services.

Here's our proposal of what the feature will look like.

Currently Traffic Ops will presents the following options for protocol

• http
• https
• https and http

Our plan is to add a fourth option

• http to https

What do these options mean for clients of the CDN?

HTTP

A cdn client connecting via http will ultimately be routed to an edge and will remain on http traffic

A cdn client that attempts to connect via https will receive back a 503 http error

HTTPS

A cdn client connecting via http will receive back a 503 error

A cdn client connecting via https will be routed to an edge and remain on https traffic

HTTP and HTTPS

A cdn client connecting via http will be routed to an edge and remain on http traffic

A cdn client connecting via https will be routed to an edge and remain on https traffic

HTTP to HTTPS

A cdn client connecting via http will be routed to an edge and switched to https traffic

A cdn client connecting via https will be routed to an edge and remain on https traffic

Certificate Management

Traffic Ops interface now allows operators to create wildcard certificate requests and keys for http delivery services 

Certificates will be managed on a per delivery service level.

This means you'll need to get a signed certificate with a wildcard common name

*.mydeliveryservice.mycdn.example.com

You'll also have to update your riak servers to be able to search the cdn level for its delivery service certs

We have documentation in place in the master github branch to explain how to do this.

It'll be on the main traffic-control-cdn.net site when the release is made.

The very first time traffic router with this feature starts it will

• create an empty Java keystore in the installation db directory (default is /opt/traffic_router/db/.keystore)
• generate a random password and store it in the conf directory (default is /opt/traffic_router/conf/keystore.properties)

Each time traffic router accesses the keystore it'll be using the password from keystore.properties

Then it'll attempt to fetch certificates for all delivery services for a cdn from the traffic ops endpoint /api/1.2/cdns/name/<cdn-name>/sslkeys.json

It'll import these certificates to the above java keystore on disk.

Afterwards it'll re-fetch certificates once an hour or any time cr-config is snapshotted.

If you want to fetch certificates at a different rate add the following parameter to traffic ops

certificates.polling.interval

and give it a numeric value, which will be the number of milliseconds between attempt to fetch certificates from traffic ops

Note that because the certificates are getting stored in a java keystore, it is possible to manage this keystore externally with the standard keytool program that comes with java.

This is possible but highly discouraged for normal day to day operations.

If for any reason Traffic Router receives a cr-config that has 

• at least one http delivery service marked to support https traffic 
• yet it cannot find certificates for one or more of those delivery services
  

then traffic router will essentially reject that new cr-config and continue using its current state.

That would mean if an existing delivery service was operating only over http traffic it will continue to do so.

A new delivery service in this rejected config would not be recognized by traffic router and clients will receive 503's.

Once this situation occurs Traffic Router will ignore any cr config updates until it receives good certificates from traffic ops.

It will continue attempting to apply the copy of the config from traffic monitor once a minute which will include attempting to fetch a copy of the certificates from traffic ops.

Notes about clients initally connecting to traffic router over https

If a client attempts connects to traffic router over https for a delivery service without a certificate it will experience a SSL / TLS handshake error.

It will not receive any kind of http error because the secure connection is essentially rejected.

This will also happen if there is some problem with the certificate given to traffic router for the requested delivery service.

Many of the above items have been implemented and merged into the master branch

Remaining work items

• Traffic Router needs to avoid applying cr-config when it cannot find the certificate for an https capable http delivery service
• Need to add http to https option for traffic ops
• currently traffic router is promoting http clients to https if possible for 'http and https' http delivery services

Please let us know of any thoughts, questions or concerns about this feature.

Cheers,

Trevor Ackerman