Drop certbot in favor of something with less dependencies

[kyrofa]

I recommend acme.sh or something similar. Requirements:

• Existing installations shouldn't even notice the switch (will require configuration migrations)
  • Existing certs should continue renewing seamlessly (see the renew-certs executable)
• Existing CLI commands and configuration parameters should not change API
  • I believe this is only the enable-https executable

[r4co0n]

Nice, there is a migrations construct available, this should make things easy. I am currently having my eyes on mod_md, which might integrate certificate generation into normal webserver operations. acme.sh is another option I'm evaluating.

[kyrofa]

That's funny, mod_md caught my eye as well. My only concern was that it was apache specific, which would get really annoying if we ever wanted to move to, say, nginx. No strong feelings though, explore.

[r4co0n]

@kyrofa, and that was my biggest concern with this choice as well. Looking forward to working on this together...

[r4co0n]

When thinking about how to migrate our users to another mechanism for providing letsencrypt or potentially any certificates from an ACME-capable authority - Scott Helme has some nice blog posts about those, here is the latest, including links to previous discussions of other providers - the hurdle of identifying the currently selected encryption method for the snap came up in #1924, quoting myself:

The biggest concern with migration is keeping everything working for all the folks that currently use certbot, and for those that have provided their own certificates. As far as I could discern, we never log what people last chose when setting up encryption, or am I mistaken? It's prudent to know if the current certificate is self-signed (generated by us), provided by letsencrypt or provided by the admin.

Is there a sane way to discern what was select as certificate source when our user last called nextcloud.enable-https?

Keep in mind that users could have been doing the switcheroo and used every possible configuration in the past, with certificates that have not yet expired. And there might well be users providing LetsEncrypt certificates using the custom mechanism, as they fetch them another way.

[kyrofa]

It's prudent to know if the current certificate is self-signed (generated by us), provided by letsencrypt or provided by the admin.
Is there a sane way to discern what was select as certificate source when our user last called nextcloud.enable-https?

Yes, see here and here. It's sane because we know how the enable-https script works, and so can keep track of the state of things that way. We have other logic built around this as well.

And there might well be users providing LetsEncrypt certificates using the custom mechanism, as they fetch them another way.

Right, we don't want to mess with those certs at all. Just the ones the snap is responsible for renewing.

[r4co0n]

Ha, I really don't know why I didn't see those, I was working with just that file. To reconcile: There are four possible states:

• Https disabled
• Https enabled with letsencrypt certificate
• Https enabled with self-signed (internally generated) certificate
• Https enabled with custom (user-provided) certificate

The relevant flags are:

• certificates_are_active - Whether the live cert directory link exists
• custom_certificates_are_active
• self_signed_certificates_are_active

Ergo:

• Https disabled: If certificates_are_active is false.
• Https enabled with self-signed certificate: If self_signed_certficates_are_active is true and certificates_are_active is true.
• Https enabled with custom certficate: If custom_certificates_are_active is true and certificates_are_active is true.
• Https enabled with letsencrypt certificate: If certificates_are_active is true and self_signed_certficates_are_active is false and custom_certificates_are_active is false.

Maybe switching to a simple enum-style variable (off, letsencrypt, self_signed, custom) would be beneficial? Currently, letsencrypt seems to be the implicit https-mode if no other was selected. Sure, it should be default, maybe we can handle this more explicitly in the code? But anyways, I think I now know how to detect the relevant states.

[kyrofa]

Eh, posix shell doesn't really have enum type stuff, so you'd end up comparing strings constantly 🤷‍♂️ .

[github-actions]

This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity.