Always use SSL for rewritten click tracking links with custom domains

[mlandauer]

Currently we use plain http for links that do link tracking. This is not ideal as the world is very quickly moving to being https everywhere.

We should automatically use let's encrypt to get SSL certificates for custom domains and use those with link tracking. That means all links will be SSL encrypted which is obviously better all round and means that we can set HSTS for root domains for applications that use custom subdomains.

See https://github.com/openaustralia/publicwhip/issues/1274 for example problem with theyvoteforyou.org.au. We also know that there are similar problems with PA.

A workaround would be to disable link tracking for the time being which I have no trouble with.

[mlandauer]

I think we can implement this without any changes to the user experience. It can happen completely automatically behind the scenes. If a user puts in a custom domain for link tracking as well as the current thing where it is checked that the custom domain points at the cuttlefish domain, we get an ssl certificate behind the scenes. When that certificate is ready and working we can then automatically use https for the open image and the link tracking links. It might be nice to show the user whether links are going to use http or https just for their own reassurance.

https://github.com/unixcharles/acme-client looks like a nice library for doing the job. I'm thinking we use a single account for all of cuttlefish. When a custom domain has been setup we start a background job for generating the SSL certificate. We'll then need to write the ssl certificate to disk for nginx and tell nginx to reload. Fun and games this will be. We'll also need a rake task that runs once per day that checks if any certificates are going to expire and regenerate them if they are.

[mlandauer]

This is now largely (maybe 3/4) implemented. What's working now:

• For apps with custom tracking domains, once per day SSL certificates are created and/or renewed
• The web server is automatically configured to serve up those certificates
• Once that's all in place the tracking links and open images are automatically switched over to using https

What's left to do:

• Immediately generate a certificate (in the background) when a custom tracking domain is updated or an app is created with a custom tracking domain
• Clean up any old certificates and web server configs that are not being used anymore
• Show in the user interface whether tracking links and open images are going out with https or http.

Some potential further work:

• Improve handling of concurrency. There is a possibility of things getting out of whack if two processes are trying to generate certificates at the same time. It would be good to come up with a simple (and reliable) fix for this. If not it's probably not a biggy as the chance of it happening in practise (at least for us right now) is pretty low.

[mlandauer]

The three things left do (from above) are now done:

• Immediately generate a certificate (in the background) when a custom tracking domain is updated or an app is created with a custom tracking domain
• Clean up any old certificates and web server configs that are not being used anymore
• Show in the user interface whether tracking links and open images are going out with https or http.

I'm not going to worry about the concurrency issue for the time being. Let's just call this done and move on