Implement automatic Let's Encrypt certificate renewal

[stcz]

Problem

Currently, if you are using certbot and a Let's Encrypt Certificate, the certificate will be renewed by certbot, but it will not be copied to nginx. This needs to be done by manually running scripts/init_letsencrypt.sh.

Further, it is currently not possible to use a own certificate from another source.

Solution

In this PR i propose a solution where you can manually set the path that NGINX is using for the Certificate.
Further, I added the certbot certificates directly to the NGINX container.

[stcz]

The code is currently just a fast proposal I have written.

I would be happy to receive some feedback if a change like this is wanted, if yes I would work further on it and test it in detail to get the PR ready. (:+1: )

If it is an unwanted feature, please let me know and I will try to find another solution for me. (:-1: )

[suricactus]

Hey, @stcz . First, very highly appreciated you contribute your solution upstream! Thank you very much!

You properly identified scripts/init_letsencrypt.sh as something one has to run manually or from a cron from the host, which is also annoying on our side.

If I read your proposal correctly, you move the whole logic to handle certificates renewal cron on the host. In a perfect universe I would prefer to have all this logic within the docker-compose configuration. One project achieving something similar is https://hub.docker.com/r/gordonchan/auto-letsencrypt/ . Personally I never had time to investigate deeper what we can do here.

As for giving full path to your certificates to support external ones, I am fully ok with that.

[stcz]

Hi @suricactus,
Thanks for your response.

Just to be sure: I not sure what you mean with:

If I read your proposal correctly, you move the whole logic to handle certificates renewal cron on the host. In a perfect universe I would prefer to have all this logic within the docker-compose configuration.

To explain it in detail:

• The configuration is done in .env (what i think is a better place, than the docker-compose file).
• The "logic" is running inside the docker containers
• The configuration is stored in a folder mounted to the filesystem. (Could also be a volume, but would produce migration/backwards compatibility issues)

I would like it, when there is no change in the docker-compose-file is needed to change the certificate source. That's why I prefer the .env.

I would prefer to not use images like the proposed auto-letsencrypt, as it doesn't look well maintained.

If the proposed way is fine i would go for testing and improving.

[stcz]

I worked again on it and changed a few things:

• The Diffie-Hellman parameters are moved to a folder
• Own 4096 bit DH parameters are only created and used for production
• The nginx tls config is not updated by init_letsencrypt.sh anymore. They should be maintained in the repository.

From my point of view, this PR is now working as intended. Can you review it and let me know if more changes are needed?

I set up a test Server and will check if the renewal is working.

For merging, I would recommend squashing my commits to one.

[suricactus]

Hey! Xmas time allowed me to have a look and it was looking quite solid, also understood why my question earlier was a bit weird. I also want to setup an internal server with this branch before merging. We might not merge it very soon, but it will become part of upstream in the next weeks.

[stcz]

Thanks, that sounds good.

When set up my testserver I changed as few as possible, I figured out #843.

I would suppose to quote all variables in .env.example. But this should be done in another PR. What do you think about this?

Further, I thought about hardining ./scripts/init_letsencrypt.sh against this issue.

What do you think about this when loading .env?

# read and export the variables from the .env file for the duration of this script
set -o allexport
source <(cat .env | sed -e '/^#/d;/^\s*$/d' -e "s/'/'\\\''/g" -e "s/=\(.*\)/='\1'/g")
set +o allexport

It is from here. But i would like to avoid.

[stcz]

I added an unrelated change in README by changing Infrastructure to h2. I or you can remove if this is unwanted.

[suricactus]

When set up my testserver I changed as few as possible, I figured out #843.

I would suppose to quote all variables in .env.example. But this should be done in another PR. What do you think about this?

Further, I thought about hardining ./scripts/init_letsencrypt.sh against this issue.

Internally we double quote the envvars with special chars in them:

ENVVAR="whatever@funky or even space"

What do you think about this when loading .env?

# read and export the variables from the .env file for the duration of this script
set -o allexport
source <(cat .env | sed -e '/^#/d;/^\s*$/d' -e "s/'/'\\\''/g" -e "s/=\(.*\)/='\1'/g")
set +o allexport

It is from here. But i would like to avoid.

Been there. Fails in certain cases unfortunately...

[suricactus]

@stcz just to let you know there was another PR that already quoted the envvars with special chars, see #846 .

[suricactus]

Hey @stcz . We are willing to merge this, can we make the tests pass. See https://github.com/opengisch/qfieldcloud/actions/runs/7861265082/job/21449439806?pr=829#step:5:12 . We have some envvars that are not available in the docker-compose.yml or .env.example.

[stcz]

Should be fixed now.

• I added the LETSENCRYPT variables to the ignore list
• I removed the default values from the compose config

[stcz]

One last question:
Has anyone done end-to-end tests? I haven't tested if it is really working and i also haven't tested if there might be any side effects on current installations when just updating.

In theory, there should be no issues. If it is merged, I would directly deploy it on my production server.

[stcz]

Do you have any ideas about the flanky test?

[suricactus]

One last question: Has anyone done end-to-end tests? I haven't tested if it is really working and i also haven't tested if there might be any side effects on current installations when just updating.

In theory, there should be no issues. If it is merged, I would directly deploy it on my production server.

Not yet, planning to do this on our internal staging server and if all good, straight to prod in few weeks.

Do you have any ideas about the flanky test?

Forget about it, it is flaky for reasons beyond your immediate control.

Thanks, will keep this PR open for some time while testing, will inform you if any issues are spotted.

[stcz]

OK.

Is master your staging branch and release the production branch?

[suricactus]

Both are using the same release branch. I will just temporarily deploy this branch on some of the internal dev servers (not necessarily staging) to see how it behaves before merging.