Azuracast: Will AzuraCast automatically renew my LetsEncrypt certificate?

[gammaw]

Hi,

the AzuraCast website says (https://www.azuracast.com/docker_sh.html#set-up-letsencrypt):

_TIP
Your LetsEncrypt certificate is valid for 3 months. The web service will automatically attempt to renew certificates every night._

Which web service? I have an AzuraCast instance up and running. Will AzuraCast automatically renew the certificate or do I have to manually renew it from time to time? In case of the latter, how can I check the time left until the certificate expires?

Thanks,

Peter

[SlvrEagle23]

@mmmnmnm AzuraCast's new unified web container (if you've updated your docker-compose.yml in the last few weeks, you're likely already using it) automatically includes LetsEncrypt cert renewal in its nightly cron tasks, so you don't need to do it on your host computer.

If you want to check the current status of all of your LE certificates, you can run:

docker-compose exec --user="azuracast" web certbot certificates

[gammaw]

@SlvrEagle23 thanks, great update! I checked (using the command above) three days after issuing the certificate and it says:

_Expiry Date: 2019-04-23 22:51:57+00:00 (VALID: 87 days)_

Shouldn't I see every time 90 or 89 here? Or what does the cron task exactly do?

[SlvrEagle23]

@mmmnmnm The cron task just calls certbot's internal renew command. This command doesn't actually renew every certificate every single night, as that's not necessary at all and would spam the LetsEncrypt servers. Instead, it checks for certificates that are near expiry (within a few weeks) and renews those, ignoring ones that have most of their 90-day period still available.

[gammaw]

@SlvrEagle23 today, all of a sudden, we couldn't reach our Azuracast server via https.
Apparently, the Letsencrypt certificate expired. After above thread, my assumption was that the certificate is being renewed automatically. It turns out that the manual renewal (./docker.sh letsencrypt-renew) doesn't work if I use custom ports (specified in .env), which we do. Can you confirm it? Can you recommend an automation for this case?

[SlvrEagle23]

@gammaw That makes sense, as it's not able to do the normal HTTP verification that it depends on. My recommendation would be to set up a cron task on the host computer that directly calls certbot and does whatever alternate method of verification you're using (i.e. DNS).

[gammaw]

@SlvrEagle23 thanks, we'll try to come up with a solution. I wonder why we didn't receive the usual notification email from Letsencrypt that the certificate is about to expire...

[gammaw]

@SlvrEagle23 it turns out that the DNS challange is tricky to automate. Is it possible to change the ports of the Azuracast server "on-the-fly" (without restarting the server)?

[SlvrEagle23]

@gammaw You can try just restarting the web container by itself, which will update the ports without shutting off the stations service.

[gammaw]

@SlvrEagle23 thanks. This is what I did:

1. Stopped web.
2. Changed the ports to default in .env so that the Letsencrypt challange will work.
3. Called docker-compose up -d. Note: calling docker-compose start web didn't work because it ignored the port mapping and kept using the custom ports.
4. Renew certificates by calling ./docker.sh letsencrypt-renew.
5. Stopped web again, changed back the custom ports in .env, called docker-compose up -d.

Everything seemed good (the Azuracast server was accessible via HTTPS again) but then I realized that the player won't play because the site https://www.domain.com:8000/radio.mp3 still showed an expired certificate. The problem didn't go away until I called docker-compose down and docker-compose up -d, which is essentially restarting the station.

I like your workaround to only stop the web container for certificate renewals so I'd be interested in fixing it. Do you have any idea why the certificates don't work on the radio station port?

[SlvrEagle23]

@gammaw Ah yeah, for Icecast to pick up the updated cert you'll have to restart the stations container (or just the station itself). Probably no zero-downtime way out of this one. :(

[gammaw]

@SlvrEagle23 thanks for confirming it.