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.
A few more thoughts on using a separate reverse proxy: all things considered, this is the most flexible approach. In theory, you could even use a Certbot HTTP challenge on port 80 without having to disable GeoBlocking for AIO.
For example:
The reverse proxy listens only on port 443 and is protected by GeoBlocking.
Certbot uses an HTTP challenge on port 80, which is not GeoBlocked.
In that setup, requests to port 80 would normally go nowhere, because Certbot only spins up a small temporary web server when requesting or renewing a certificate and shuts it down again afterward.
That’s just one option among many. If you don’t want to expose anything to the internet at all, you can use one of the DNS challenge methods instead.
Alternatively, you could open a feature request on the AIO GitHub and ask for these capabilities to be integrated directly into AIO and/or for the “short-lived” certificate option to become configurable. Whether that would actually get implemented is another question.
That said, as I mentioned before, the latter only makes limited sense. By 2029, even “long-lived” certificates will only be valid for a maximum of 47 days. In practice, this means renewing certificates every 30 days, which, in my opinion, is not really suitable for building manual processes around it anymore.
And let’s be honest: manually maintaining certificates was never a good solution, not even back when certificates could be valid for three years. People forget, certificates expire, services go down, and everyone has a bad day. Automation is simply the better approach, and once you have implemented it, you may as well use short-lived certificates and benefit from the increased security they provide.
Provided the certificate is automatically renewed and the domain name doesn’t change, there’s no need to reconfirm anything. My calendars on my phone have been synced with Nextcloud for years and I’ve never had to confirm anything after the certificates on the server were renewed.
Just for clarification regarding port 80, since my previous post may have been a bit confusing:
In its default configuration, Nextcloud AIO only requires port 443 to be reachable from the internet. Simply forward port 443, and AIO will automatically obtain and renew certificates using the TLS-ALPN-01 challenge. You don’t need to do anything manually, either on the server or on the clients. In practice, you won’t notice any difference whether certificates are renewed every 60 days, every week, or every day. It just works.
If you’re using a reverse proxy in front of AIO because you’re exposing additional services, then it depends on the reverse proxy and which ACME challenge method it uses. For example, Caddy uses the HTTP challenge by default and therefore requires port 80.
However, that’s generally not a problem, and you don’t really gain any additional security by keeping port 80 closed and only opening it temporarily for certificate renewals. By default, port 80 is simply configured to redirect HTTP traffic to HTTPS. Here’s an example from my Caddy instance with the default configuration:
curl -I http://cloud.domain.tld
HTTP/1.1 308 Permanent Redirect
Connection: close
Location: https://cloud.domain.tld/
Server: Caddy
Date: Thu, 04 Jun 2026 08:17:24 GMT
So, in practice, you gain virtually nothing by manually opening and closing port 80 just for certificate renewals. What you do gain is the risk of forgetting to do it in time, causing your certificates to expire and your services to stop working.
