Is it possible to get the old Let’s encrypt certificate runtime back?
I know that they will reduce the runtime later. But cert troubles every week is bad.
If automatic renewal is working properly, there shouldn’t be any issues with the certificate every week, right? Is this just a concern of yours, or are you actually having problems with automatic renewal? If the latter is the case, wouldn’t it be better trying to fix the root cause?
However, if you change this in the container, it will most likely be overwritten during the next update, so it would be better to use your own reverse proxy in front of AIO and manage the certificates with that. all-in-one/reverse-proxy.md at main · nextcloud/all-in-one · GitHub
But again, the best solution is to ensure that automatic renewal works properly, because then it won’t matter how long or short the validity period of the certificates actually is.
I never read all all possible solutions on Letsencrypt-site. It surely might be possible to retrieve a certificate with a longer renewal range.
As @bb77 mentioned above, you might get into trouble, if you do manual settings, which might be overwritten at next upgrade.
The background is, that Letsencrypt changes the period of validity step by step due to more security generally. So, we should follow that guideline.
I somewhere read at the beginning of this year, that Google will force to decrase the validity range of SSL certificates down to one week in the future.
Yes, but not because of Let’s Encrypt or Caddy. Both still have a default validity period of 90 days and an automatic renewal period of 60 days. This has been explicitly configured this way in AIO. However, if you remove the relevant line from the Caddyfile, it will be re-added when you recreate the container.
I guess in theory, @szaimen could add a variable for this, which could then be passed to the container as an environment variable when it is started. However, I don’t think that it would be worth the effort, because if automatic renewal works properly, short lived certs aren’t an issue, and i you need different settings for whatever reason, or different challenge methods, or want to use a different certificate authority to Let’s Encrypt etc, you would need to use your own reverse proxy anyway.
Yes, absolutely. Automation will be inevitable sooner or later, because manual renewal, regardless of the CA, will no longer be feasible. So it’s better to make sure now that you have proper automation in place.
Well, if for example one has GeoIP blocking activated or does not want to keep open port 80 all the time … Opening the port and GeoIP once every 2-3 months is not the same as opening them every 6 days. With 6 days one is “forced” to deactivate such firewall rules.
The “fix” for another problem is interfering with the Let’s Encrypt policy.
Some very small Nextcloud installations are under permanent attack. The simple solution is a geo-filter in the firewall.
If we disable the filter, the attacks will start again soon. Nextcloud is just busy delivering the login page ten times per second. We use scheduled firewall rules to allow cert update after nextcloud backup. But timing is difficult and it works not very well.
Sure, lets wrap another virtual machine around the nextcloud, waste another gigabyte of ram.
Or just add some script lines like “if folder contains pfx file, use this, and skip Let’s encrypt”.
But i am just a user. Don’t know if this is possible at all.
Letsencrypt allows renewal without usage of port 80 but by using a txt-entry in DNS of your provider/DynDNS-provider. You will find more information about that in the Letsencrypt documentation.
