I have set up a VPS, installed certbot and managed to run Phoenix 1.5.7 using HTTPS.
The paths to the key and cert files from lets encrypt are read by phoenix from ENV variables in the prod.secret.exs file.
The files will be renewed automatically by certbot every 3 months using a cron job.
I can’t find answers to the following questions:
How to deal with the renewal of the keys on the Phoenix side? Do I have to restart the Phoenix server or will Phoenix read the updated files in due time?
Would the situation be the same with the new elixir runtime config files?
I would appreciate any insights on these issues which are new to me.
Thanks in advance for your help.
While I don’t know the exact answers to your questions, maybe you can find some insights from this library.
And if you would accept bringing a dependency to your app, you could use the library to manage your certificates and eventually ditch certbot.
I use certbot’s webroot option and basically tell it to go use /my/compose/root/certbot, which gets mounted at /app/certbot, which cowboy will serve at /, and it all just works.
First run you have to shuffle some mess around but it’s easier to use certbot’s own webserver to generate the first set of certs, then change it to use webroot.
The SSL guide recommends you use the fullchain.pem file for atomic updates, you don’t have to restart phx.
I am also using it for now, but be very careful with trusting in the headers because they don’t cleanup the headers as they should. For example, the x-forward-for is set by them, but it can also be set by the client sending the request, thus you end-up with two ips in your backend:
That is true, overwritten headers could be an issue. But maybe it is not an issue for @damien I find it nice not to care about certificate renewal.
Regarding the overwritten headers… what if you configure traefik / your LB to use some other, “unforgeable” name for the header, e.g. X-Forwarded-34535435987-For?
Could be a workaround if Traefik allows for that, but then you also need to account for that in software that assumes the standard header for the proxy to be the x-fowarded-for.
I was loving Traefik until I discovered this issue and that they kept “refusing” to fix it, despite open bugs.
So, I will have to ditch Traefik in a near future, because if they screw-up in the basics of security and won’t fix I don’t even want to imagine what else they got fundamentally wrong.
If those files are updated, I think you don’t need to restart anything and the new certs will be eventually picked up. FWIW site_encrypt forces this manually by invoking :ssl.clear_pem_cache.