Hi there, I’m doing this post to better inform the community and also ask for validation.
We have been using openBalena for a while now (it’s an awesome product btw!) but our concerns recently shifted to SSL certificates expiration. As we know, API and VPN certs are created with a validity of 2 years which is not a lot. We did several attempts to ensure the certificate renewal process would complete without any problems as the whole system depends on it (correct me if I’m wrong).
We did different tests and I thought it may be useful to share them with the community.
Let’s Encrypt automatic certificate renewal
We tried to use
-c parameter in the
quickstart command during open-balena installation but we had no luck: the
cert-provider always reported an error of some kind, never leaving the staging phase. Reading this forum we did some progress changing ACME version pulled from github, commenting two line in the .sh script but after all, we weren’t able to accomplish a self-renewing certificate, even with different “hacks” which didn’t give us much confidence, to begin with.
Manually renewing the certificates
We tried to manually renew the server certificate using the automatically generated CA (which you can find in
open-balena/config/certs/root) and we were able to “install” it in open-balena placing the .pem file in
open-balena/src/haproxy/open-balena.pem and rebuilding the container. With this procedure, we were able to make the HTTPS API be served with a newly generated certificate with a custom expiration date. This procedure, although kinda hacky, seemed to be working, but we had no idea what should have been done VPN-wise as we saw there is a dedicated folder in
open-balena/config/certs/vpn. Since this way still seemed too hacky and we still had doubts about the VPN we tried a different route.
Changing certificates duration upon quickstart
We noticed the
ssl-common.sh (which is invoked in the quickstart process) in open-balena source files contains a couple of useful variables:
# global expiry settings CA_EXPIRY_DAYS=3650 CRT_EXPIRY_DAYS=730
Changing those variables to a greater timespan and re-running the quickstart from scratch (after a cleanup of docker volumes) did produce an open-balena setup with a custom certificates expiration and, honestly, it actually seems a pretty solid solution. AFAIK this is valid only for a fresh start of the system and cannot be done for an existing and running instance. Of course, an 500y lasting certificate may not be great from a security point of view but it’s still better than a certificate expiring in 2 years without a proper way to renew it without using some hack.
We know open-balena is marked as not production-ready, so we completely understand automated LE certificates renewal process may not be fully working flawlessly yet and that’s ok. What we did find quite frustrating was how difficult changing the certificate’s validity seemed to be. Let’s go straight to the point: if anyone uses open-balena as it is without digging deep inside the forum, is basically using a demo version of the software which is set to expire after 2 years (correct me if I’m wrong here). The solution is there: just change the ssl-common.sh variables but it’s actually not very well documented and, since it’s something which must be set upon initial installation, I think certificates management with possible solutions are worth mentioning in the getting-started section.
Please don’t take this post as an attack. We just wanted to add our perspective and highlight a possible concern also giving future users a hint about what can be done. Balena ecosystem is an amazing world we all love, I’m just trying to make life easier for future users!