starred/nginx-proxy-manager-NginxProxyManager
1
0
Fork 0
mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-25 17:35:52 +03:00
Code Issues 937 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #677] Customize SSL cert renewing interval to avoid reloading nginx every hour #573

New issue
Open
opened 2026-02-26 06:33:27 +03:00 by kerem · 31 comments
kerem commented 2026-02-26 06:33:27 +03:00
Owner
Copy link

Originally created by @niklasdahlheimer on GitHub (Oct 26, 2020).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/677

Is your feature request related to a problem? Please describe.
First of all: great tool! Setting up reverse poxies is really fun with this one :)

According to the docker logs, npm is checking for expired certificates every hour:

[10/26/2020] [1:26:22 AM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[10/26/2020] [1:26:24 AM] [Nginx    ] › ℹ  info      Reloading Nginx
[10/26/2020] [1:26:24 AM] [SSL      ] › ℹ  info      Renew Complete
[10/26/2020] [2:26:22 AM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[10/26/2020] [2:26:24 AM] [Nginx    ] › ℹ  info      Reloading Nginx
[10/26/2020] [2:26:24 AM] [SSL      ] › ℹ  info      Renew Complete
[10/26/2020] [3:26:22 AM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[10/26/2020] [3:26:23 AM] [Nginx    ] › ℹ  info      Reloading Nginx
[10/26/2020] [3:26:23 AM] [SSL      ] › ℹ  info      Renew Complete
[...]

I think reloading nginx every hour could lead to problems in the business times of our web services (e.g. downloads buffered by nginx ..)

Is there a way to customize the cron job which triggers the cert renewing every hour to start the renewing only once a day or so?

Describe the solution you'd like
some way (UI or production.config) to customize the renewal interval

Originally created by @niklasdahlheimer on GitHub (Oct 26, 2020). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/677 **Is your feature request related to a problem? Please describe.** First of all: great tool! Setting up reverse poxies is really fun with this one :) According to the docker logs, npm is checking for expired certificates every hour: ``` [10/26/2020] [1:26:22 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [10/26/2020] [1:26:24 AM] [Nginx ] › ℹ info Reloading Nginx [10/26/2020] [1:26:24 AM] [SSL ] › ℹ info Renew Complete [10/26/2020] [2:26:22 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [10/26/2020] [2:26:24 AM] [Nginx ] › ℹ info Reloading Nginx [10/26/2020] [2:26:24 AM] [SSL ] › ℹ info Renew Complete [10/26/2020] [3:26:22 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [10/26/2020] [3:26:23 AM] [Nginx ] › ℹ info Reloading Nginx [10/26/2020] [3:26:23 AM] [SSL ] › ℹ info Renew Complete [...] ``` I think reloading nginx every hour **could lead to problems** in the business times of our web services (e.g. downloads buffered by nginx ..) **Is there a way to customize the cron job which triggers the cert renewing every hour to start the renewing only once a day or so?** **Describe the solution you'd like** some way (UI or production.config) to customize the renewal interval
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@papatistos commented on GitHub (Aug 19, 2021):

I don't quite understand why the renewing interval is set to such a short period in the first place. I think, letsencrypt certs are usually valid for three months or so. Why do 2160 checks during that period?

<!-- gh-comment-id:901654294 --> @papatistos commented on GitHub (Aug 19, 2021): I don't quite understand why the renewing interval is set to such a short period in the first place. I think, letsencrypt certs are usually valid for three months or so. Why do 2160 checks during that period?
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@niklasdahlheimer commented on GitHub (Aug 19, 2021):

probably it's just changing
github.com/jc21/nginx-proxy-manager@4f10d129c2/backend/internal/certificate.js (L24)
to
intervalTimeout: (process.env.CERTIFICATE_RENEWAL_INTERVAL_IN_SECONDS * 1000) || (1000 * 60 * 60), // 1 hour

Than the environment variable CERTIFICATE_RENEWAL_INTERVAL_IN_SECONDS could be used to set the preferred interval.

Sadly I'm not able to setup a working build environment to test it to create a pull request :/

<!-- gh-comment-id:902237352 --> @niklasdahlheimer commented on GitHub (Aug 19, 2021): probably it's just changing https://github.com/jc21/nginx-proxy-manager/blob/4f10d129c20cc82494b95cc94b97f859dbd4b54d/backend/internal/certificate.js#L24 to `intervalTimeout: (process.env.CERTIFICATE_RENEWAL_INTERVAL_IN_SECONDS * 1000) || (1000 * 60 * 60), // 1 hour` Than the environment variable `CERTIFICATE_RENEWAL_INTERVAL_IN_SECONDS ` could be used to set the preferred interval. Sadly I'm not able to setup a working build environment to test it to create a pull request :/
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@CorvetteCole commented on GitHub (Aug 27, 2021):

this really need to be changed, I'm sure lets encrypt doesn't particularly appreciate it either

<!-- gh-comment-id:907410797 --> @CorvetteCole commented on GitHub (Aug 27, 2021): this really need to be changed, I'm sure lets encrypt doesn't particularly appreciate it either
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@chaptergy commented on GitHub (Aug 27, 2021):

Letsencrypt does not notice this, as it is only checked locally whether a certificate is due to expire within a month, and only then a request to letsencrypt ist made. The only "issue" this high renewal rate causes is a slightly higher than necessary CPU consumption every hour. So NPM would be made more efficient by changing this, but this is not very urgent. Which does not mean that it should not be changed.

<!-- gh-comment-id:907431442 --> @chaptergy commented on GitHub (Aug 27, 2021): Letsencrypt does not notice this, as it is only checked locally whether a certificate is due to expire within a month, and only then a request to letsencrypt ist made. The only "issue" this high renewal rate causes is a slightly higher than necessary CPU consumption every hour. So NPM would be made more efficient by changing this, but this is not very urgent. Which does not mean that it should not be changed.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@niklasdahlheimer commented on GitHub (Aug 28, 2021):

@chaptergy I agree with you that certbot will only contact letsEncrypt if a certificate really expires within the next 30 days:
"[...]Since renew only renews certificates that are near expiry it can be run as frequently as you want - since it will usually take no action.[...]"
https://certbot.eff.org/docs/using.html?highlight=renew#renewing-certificates

But my concerns where more about the reload of nginx, which, I think, is triggered every time the task is run, so every hour. See
github.com/jc21/nginx-proxy-manager@5c67908460/backend/internal/certificate.js (L55)

I'm not so much into nginx but couldn't this might cause running connections to "hickup" or result in a denial of service if you do a request just in this reload interval?
Either way, this hourly reload is not nescessary and I think it's easy to avoid it by implementing a environment variable, just like I suggested above.
...Or just increase the interval...Actually every value below 30 days should be enough

<!-- gh-comment-id:907588060 --> @niklasdahlheimer commented on GitHub (Aug 28, 2021): @chaptergy I agree with you that certbot will only contact letsEncrypt if a certificate really expires within the next 30 days: _"[...]Since renew only renews certificates that are near expiry it can be run as frequently as you want - since it will usually take no action.[...]"_ https://certbot.eff.org/docs/using.html?highlight=renew#renewing-certificates **But** my concerns where more about the reload of nginx, which, I think, is triggered every time the task is run, so every hour. See https://github.com/jc21/nginx-proxy-manager/blob/5c679084605a79d98661a65eb272a06fc8cb5669/backend/internal/certificate.js#L55 I'm not so much into nginx but couldn't this might cause running connections to "hickup" or result in a denial of service if you do a request just in this reload interval? Either way, this hourly reload is not nescessary and I think it's easy to avoid it by implementing a environment variable, just like I suggested above. ...Or just increase the interval...Actually every value below 30 days should be enough
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@chaptergy commented on GitHub (Aug 29, 2021):

It seems the original intention was to not run certbot at boot since you can't execute other certbot commands while it is running. And to make sure certbot runs even if you restart frequently, the hourly interval was chosen.

<!-- gh-comment-id:907798093 --> @chaptergy commented on GitHub (Aug 29, 2021): It seems the original intention was to not run certbot at boot since you can't execute other certbot commands while it is running. And to make sure certbot runs even if you restart frequently, the hourly interval was chosen.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@papatistos commented on GitHub (Aug 29, 2021):

Thanks for the explanation. At least it makes some sense now. But the same could also be achieved by running certbot exactly once an hour after boot and thereafter once every couple of weeks or so.

<!-- gh-comment-id:907824822 --> @papatistos commented on GitHub (Aug 29, 2021): Thanks for the explanation. At least it makes some sense now. But the same could also be achieved by running certbot exactly once an hour after boot and thereafter once every couple of weeks or so.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@marcb1387 commented on GitHub (Feb 7, 2022):

I'm having this same thing occur and getting 522 error on my pages around the time when it reloads nginx. All of my certs are months off from expiration. If this could be scheduled during off time one a day it would be great.

[2/7/2022] [9:05:39 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry...
[2/7/2022] [9:05:41 PM] [Nginx ] › ℹ info Reloading Nginx
[2/7/2022] [9:05:41 PM] [SSL ] › ℹ info Renew Complete

<!-- gh-comment-id:1031946376 --> @marcb1387 commented on GitHub (Feb 7, 2022): I'm having this same thing occur and getting 522 error on my pages around the time when it reloads nginx. All of my certs are months off from expiration. If this could be scheduled during off time one a day it would be great. [2/7/2022] [9:05:39 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [2/7/2022] [9:05:41 PM] [Nginx ] › ℹ info Reloading Nginx [2/7/2022] [9:05:41 PM] [SSL ] › ℹ info Renew Complete
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@RafaelSchridi commented on GitHub (Mar 31, 2022):

Since it renews when expiry is <30 days I see absolutely no reason to run this so often, should be at the minimum a 1 day interval.

<!-- gh-comment-id:1085227557 --> @RafaelSchridi commented on GitHub (Mar 31, 2022): Since it renews when expiry is <30 days I see absolutely no reason to run this so often, should be at the minimum a 1 day interval.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@LucidityCrash commented on GitHub (Apr 1, 2022):

this issues an nginx reload not a restart ... reload doesn't kill existing connections :

    nginx -s reload

Once the master process receives the signal to reload configuration, it checks the syntax validity of the
new configuration file and tries to apply the configuration provided in it. If this is a success, the master
process starts new worker processes and sends messages to old worker processes, requesting them to
shut down. Otherwise, the master process rolls back the changes and continues to work with the old 
configuration. Old worker processes, receiving a command to shut down, stop accepting new connections
and continue to service current requests until all such requests are serviced. After that, the old worker
processes exit.
<!-- gh-comment-id:1085657009 --> @LucidityCrash commented on GitHub (Apr 1, 2022): this issues an nginx reload not a restart ... reload doesn't kill existing connections : ``` nginx -s reload Once the master process receives the signal to reload configuration, it checks the syntax validity of the new configuration file and tries to apply the configuration provided in it. If this is a success, the master process starts new worker processes and sends messages to old worker processes, requesting them to shut down. Otherwise, the master process rolls back the changes and continues to work with the old configuration. Old worker processes, receiving a command to shut down, stop accepting new connections and continue to service current requests until all such requests are serviced. After that, the old worker processes exit. ```
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@frabnet commented on GitHub (May 3, 2022):

Customizing renew interval can be also useful to improve security or avoid unwanted network traffic.
Now the port 80 tcp is opened in every moment since we don't know when the renew will happen.
If the renew is running in a scheduled moment, we can open the 80 port only on (for example) Sunday from 23:25 to 23:35.
It's not a big security problem but the 80 port is much common, surely we can avoid some potential problems.
Anyway, I'm open to suggestions.

<!-- gh-comment-id:1116244294 --> @frabnet commented on GitHub (May 3, 2022): Customizing renew interval can be also useful to improve security or avoid unwanted network traffic. Now the port 80 tcp is opened in every moment since we don't know when the renew will happen. If the renew is running in a scheduled moment, we can open the 80 port only on (for example) Sunday from 23:25 to 23:35. It's not a big security problem but the 80 port is much common, surely we can avoid some potential problems. Anyway, I'm open to suggestions.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@LucidityCrash commented on GitHub (May 3, 2022):

Now the port 80 tcp is opened in every moment since we don't know when the renew will happen.

Is it really opening port 80 though ... I don't claim to be an expert but it doesn't make sense to me for it to be attaching to port 80 if there isn't a certificate to renew ... that said I use the cloudflare dns method so it never opens port 80 and I can't test either

however from the certbot docs :

certbot renew

This command attempts to renew any previously-obtained certificates that expire in less than 30 days. 
The same plugin and options that were used at the time the certificate was originally issued will be used
for the renewal attempt, unless you specify other plugins or options. Unlike certonly, renew acts on
multiple certificates and always takes into account whether each one is near expiry. Because of this, 
renew is suitable (and designed) for automated use, to allow your system to automatically renew each
certificate when appropriate. Since renew only renews certificates that are near expiry it can be run as
frequently as you want - since it will usually take no action.

Note this bit it can be run as frequently as you want - since it will usually take no action It really does seem to suggest that this is not doing what you seem to believe it is doing.

<!-- gh-comment-id:1116257069 --> @LucidityCrash commented on GitHub (May 3, 2022): > Now the port 80 tcp is opened in every moment since we don't know when the renew will happen. Is it really opening port 80 though ... I don't claim to be an expert but it doesn't make sense to me for it to be attaching to port 80 if there isn't a certificate to renew ... that said I use the cloudflare dns method so it never opens port 80 and I can't test either however from the certbot docs : ``` certbot renew This command attempts to renew any previously-obtained certificates that expire in less than 30 days. The same plugin and options that were used at the time the certificate was originally issued will be used for the renewal attempt, unless you specify other plugins or options. Unlike certonly, renew acts on multiple certificates and always takes into account whether each one is near expiry. Because of this, renew is suitable (and designed) for automated use, to allow your system to automatically renew each certificate when appropriate. Since renew only renews certificates that are near expiry it can be run as frequently as you want - since it will usually take no action. ``` Note this bit **it can be run as frequently as you want - since it will usually take no action** It really does seem to suggest that this is not doing what you seem to believe it is doing.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@frabnet commented on GitHub (May 4, 2022):

I don't want to criticize, just clarify: I assure you that the port 80 is always opened and always responsive, even when a renew is not needed:

frab@test:~$ curl --head http://website
HTTP/1.1 301 Moved Permanently
Server: openresty
Date: Wed, 04 May 2022 07:37:15 GMT
Content-Type: text/html
Content-Length: 166
Connection: keep-alive
Location: https://website/

With a scheduled renew timing, it could be closed by the user firewall (it can be a hardware firewall or iptables rule in the container).

UPDATE: I just found Let's Encrypt suggest to keep the 80 port open: https://letsencrypt.org/docs/allow-port-80/
I'm still convinced it's not a good way of managing it, but wathever 🙇

<!-- gh-comment-id:1117028642 --> @frabnet commented on GitHub (May 4, 2022): I don't want to criticize, just clarify: I assure you that the port 80 is always opened and always responsive, even when a renew is not needed: ``` frab@test:~$ curl --head http://website HTTP/1.1 301 Moved Permanently Server: openresty Date: Wed, 04 May 2022 07:37:15 GMT Content-Type: text/html Content-Length: 166 Connection: keep-alive Location: https://website/ ``` With a scheduled renew timing, it could be closed by the user firewall (it can be a hardware firewall or iptables rule in the container). UPDATE: I just found Let's Encrypt suggest to keep the 80 port open: https://letsencrypt.org/docs/allow-port-80/ I'm still convinced it's not a good way of managing it, but wathever :bow:
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@LucidityCrash commented on GitHub (May 4, 2022):

I'm really confused here, I certainly don't think you are critizing, I just think we seem to have a missunderstanding :)

The points I've made are that

  1. NPM does an nginx reload which wont interrupt a existing connection
  2. certbot only actually actually does the renew process when there is something to renew.

Looking at the cert code in NPM :
Initial cert request - github.com/NginxProxyManager/nginx-proxy-manager@14b889a85f/backend/internal/certificate.js (L835)
and renewal - github.com/NginxProxyManager/nginx-proxy-manager@14b889a85f/backend/internal/certificate.js (L42)
(renews are done with the same authenticator as the initial request)

I can see that if you do not use the DNS challenge method then it will use certbot with the webroot auth method with certonly ... this means that the web service, in this case nginx, is not restarted. certbot adds files to specific paths for the auth process - https://eff-certbot.readthedocs.io/en/stable/using.html?highlight=renew#webroot

So in short even if you don't use dns challenge for LE your sites should never be unavailable (slight caveat on that - github.com/NginxProxyManager/nginx-proxy-manager@14b889a85f/backend/internal/certificate.js (L131) if you create a new certificate that has a domain name in that is already in another cert then the site using that other cert gets disabled while the new cert is being created)

I'm rereading what you are saying and I think I understand what you are saying Port 80 is always listening and you'd like to be able to disable port 80 completely (except for cert renewals) ?

If that is the case then I don't think this is done because of LE ... this is simply the way NPM sets up its server config files you kinda have have to have it listening on port 80 else how would you serve up sites that you don't want SSLd ? and if you enable "force SSL" on a site then extra config is injected for that site that puts in that redirect you posted.

OK you could argue that in this day and age why would you not SSL everything but this is a generic Proxy, you have to account for all use cases and as you pointed out yourself having port 80 open is no real security threat - though changing the default site to something other than the Congratulations and 404 page is probably a good idea as both of those give hints as to what is running ... the custom page option does too as it sets the server header :( But that doesn't really increase the attack surface just gives them a little more info that will save them all of 10 seconds.

<!-- gh-comment-id:1117137440 --> @LucidityCrash commented on GitHub (May 4, 2022): I'm really confused here, I certainly don't think you are critizing, I just think we seem to have a missunderstanding :) The points I've made are that 1. NPM does an nginx reload which wont interrupt a existing connection 2. certbot only actually actually does the renew process when there is something to renew. Looking at the cert code in NPM : Initial cert request - https://github.com/NginxProxyManager/nginx-proxy-manager/blob/14b889a85f2f8af9a13ed6122f5a0a91d64ecc36/backend/internal/certificate.js#L835 and renewal - https://github.com/NginxProxyManager/nginx-proxy-manager/blob/14b889a85f2f8af9a13ed6122f5a0a91d64ecc36/backend/internal/certificate.js#L42 (renews are done with the same authenticator as the initial request) I can see that if you do not use the DNS challenge method then it will use certbot with the webroot auth method with certonly ... this means that the web service, in this case nginx, is not restarted. certbot adds files to specific paths for the auth process - https://eff-certbot.readthedocs.io/en/stable/using.html?highlight=renew#webroot So in short even if you don't use dns challenge for LE your sites should never be unavailable (slight caveat on that - https://github.com/NginxProxyManager/nginx-proxy-manager/blob/14b889a85f2f8af9a13ed6122f5a0a91d64ecc36/backend/internal/certificate.js#L131 if you create a new certificate that has a domain name in that is already in another cert then the site using that other cert gets disabled while the new cert is being created) I'm rereading what you are saying and I think I understand what you are saying Port 80 is always listening and you'd like to be able to disable port 80 completely (except for cert renewals) ? If that is the case then I don't think this is done because of LE ... this is simply the way NPM sets up its server config files you kinda have have to have it listening on port 80 else how would you serve up sites that you don't want SSLd ? and if you enable "force SSL" on a site then extra config is injected for that site that puts in that redirect you posted. OK you could argue that in this day and age why would you not SSL everything but this is a generic Proxy, you have to account for all use cases and as you pointed out yourself having port 80 open is no real security threat - though changing the default site to something other than the Congratulations and 404 page is probably a good idea as both of those give hints as to what is running ... the custom page option does too as it sets the server header :( But that doesn't really increase the attack surface just gives them a little more info that will save them all of 10 seconds.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@waytosahil commented on GitHub (Aug 27, 2022):

I see it is mentioned in above thread that request is sent to Let's Encrypt only if the cert is due for renewal and renewal check done locally (my understanding from above thread).

One observation from my setup, I have 19 certs installed and I can see in the last 24 hrs ~700 requests were made by NPM to lencr.org , which are too many request in my opinion for certs with expiry time > 2 Months. May be if we can have an option to manage it would really help optimize things.

<!-- gh-comment-id:1229155583 --> @waytosahil commented on GitHub (Aug 27, 2022): I see it is mentioned in above thread that request is sent to Let's Encrypt only if the cert is due for renewal and renewal check done locally (my understanding from above thread). One observation from my setup, I have 19 certs installed and I can see in the last 24 hrs ~700 requests were made by NPM to lencr.org , which are too many request in my opinion for certs with expiry time > 2 Months. May be if we can have an option to manage it would really help optimize things.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@pShota commented on GitHub (Nov 16, 2022):

(bump) may I ask any update on this?

<!-- gh-comment-id:1316933323 --> @pShota commented on GitHub (Nov 16, 2022): (bump) may I ask any update on this?
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@kirby12bit commented on GitHub (Apr 15, 2023):

I would like to add to this thread (know it's old but it's still open) this is causing a hiccup with using streams. I am running minecraft servers and this is causing external connections to drop during each reload.

<!-- gh-comment-id:1509448528 --> @kirby12bit commented on GitHub (Apr 15, 2023): I would like to add to this thread (know it's old but it's still open) this is causing a hiccup with using streams. I am running minecraft servers and this is causing external connections to drop during each reload.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@sercanyaldiz commented on GitHub (May 4, 2023):

Any update on this?

My certificate expires 11th July 2023, 2:45 am

Why does NPM renew my SSL cert every 1 hour?

[5/4/2023] [3:19:54 PM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[5/4/2023] [3:19:54 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[5/4/2023] [3:19:54 PM] [SSL      ] › ℹ  info      Renew Complete
[5/4/2023] [4:19:54 PM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[5/4/2023] [4:19:54 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[5/4/2023] [4:19:54 PM] [SSL      ] › ℹ  info      Renew Complete
[5/4/2023] [5:19:54 PM] [IP Ranges] › ℹ  info      Fetching IP Ranges from online services...
[5/4/2023] [5:19:54 PM] [IP Ranges] › ℹ  info      Fetching https://ip-ranges.amazonaws.com/ip-ranges.json
[5/4/2023] [5:19:54 PM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[5/4/2023] [5:19:54 PM] [IP Ranges] › ℹ  info      Fetching https://www.cloudflare.com/ips-v4
[5/4/2023] [5:19:54 PM] [IP Ranges] › ℹ  info      Fetching https://www.cloudflare.com/ips-v6
[5/4/2023] [5:19:54 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[5/4/2023] [5:19:54 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[5/4/2023] [5:19:54 PM] [SSL      ] › ℹ  info      Renew Complete
[5/4/2023] [6:19:54 PM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[5/4/2023] [6:19:54 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[5/4/2023] [6:19:54 PM] [SSL      ] › ℹ  info      Renew Complete
[5/4/2023] [7:19:54 PM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[5/4/2023] [7:19:54 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[5/4/2023] [7:19:54 PM] [SSL      ] › ℹ  info      Renew Complete
<!-- gh-comment-id:1535329301 --> @sercanyaldiz commented on GitHub (May 4, 2023): Any update on this? My certificate expires 11th July 2023, 2:45 am Why does NPM renew my SSL cert every 1 hour? ``` [5/4/2023] [3:19:54 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [5/4/2023] [3:19:54 PM] [Nginx ] › ℹ info Reloading Nginx [5/4/2023] [3:19:54 PM] [SSL ] › ℹ info Renew Complete [5/4/2023] [4:19:54 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [5/4/2023] [4:19:54 PM] [Nginx ] › ℹ info Reloading Nginx [5/4/2023] [4:19:54 PM] [SSL ] › ℹ info Renew Complete [5/4/2023] [5:19:54 PM] [IP Ranges] › ℹ info Fetching IP Ranges from online services... [5/4/2023] [5:19:54 PM] [IP Ranges] › ℹ info Fetching https://ip-ranges.amazonaws.com/ip-ranges.json [5/4/2023] [5:19:54 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [5/4/2023] [5:19:54 PM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v4 [5/4/2023] [5:19:54 PM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v6 [5/4/2023] [5:19:54 PM] [Nginx ] › ℹ info Reloading Nginx [5/4/2023] [5:19:54 PM] [Nginx ] › ℹ info Reloading Nginx [5/4/2023] [5:19:54 PM] [SSL ] › ℹ info Renew Complete [5/4/2023] [6:19:54 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [5/4/2023] [6:19:54 PM] [Nginx ] › ℹ info Reloading Nginx [5/4/2023] [6:19:54 PM] [SSL ] › ℹ info Renew Complete [5/4/2023] [7:19:54 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [5/4/2023] [7:19:54 PM] [Nginx ] › ℹ info Reloading Nginx [5/4/2023] [7:19:54 PM] [SSL ] › ℹ info Renew Complete ```
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@JOHLC commented on GitHub (Jun 8, 2023):

I also agree that a configurable renewal period would be a good feature. I have multiple instances requesting certs, every hour seems excessive.

<!-- gh-comment-id:1581834827 --> @JOHLC commented on GitHub (Jun 8, 2023): I also agree that a configurable renewal period would be a good feature. I have multiple instances requesting certs, every hour seems excessive.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@MyCleverGirl commented on GitHub (Jun 10, 2023):

ugh
im having the same issues, every hour all domains go offline untill its done and reloads, i tried to change the (1000 * 60 * 60) to 30 days and i get a sqlite error in docker logs and system breaks till i re- add (1000 * 60 * 60). im thinking of looking for alternative software, its a great program but this issue makes me wanna go elese were. they need to have a area in the online portal to allow us to change this based off user needs.

<!-- gh-comment-id:1585818062 --> @MyCleverGirl commented on GitHub (Jun 10, 2023): ![ugh](https://github.com/NginxProxyManager/nginx-proxy-manager/assets/66352498/bfe4d05e-8357-4e30-a1ab-98b25c3d892e) im having the same issues, every hour all domains go offline untill its done and reloads, i tried to change the (1000 * 60 * 60) to 30 days and i get a sqlite error in docker logs and system breaks till i re- add (1000 * 60 * 60). im thinking of looking for alternative software, its a great program but this issue makes me wanna go elese were. they need to have a area in the online portal to allow us to change this based off user needs.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@fullmetalbrackets commented on GitHub (Jul 14, 2023):

This issue has been open since 2020, will it ever be resolved or even acknowledged by the maintainers? I don't even use SSL certificates, I only proxy my Docker containers to *.home.arpa locally via http, and it still does this renewal every hour on the hour. There aren't even any SSL certificates to renew!

<!-- gh-comment-id:1636209970 --> @fullmetalbrackets commented on GitHub (Jul 14, 2023): This issue has been open since 2020, will it ever be resolved or even acknowledged by the maintainers? I don't even use SSL certificates, I only proxy my Docker containers to `*.home.arpa` locally via http, and it still does this renewal every hour on the hour. There aren't even any SSL certificates to renew!
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@HomemadeAdvanced commented on GitHub (Jul 14, 2023):

Nginx Proxy Manager V3 will be released. It is in development since two years. So it is obvious that the developers invest not that much afford into the NPM V2 anymore.
https://github.com/NginxProxyManager/nginx-proxy-manager/discussions/1202

<!-- gh-comment-id:1636241529 --> @HomemadeAdvanced commented on GitHub (Jul 14, 2023): Nginx Proxy Manager V3 will be released. It is in development since two years. So it is obvious that the developers invest not that much afford into the NPM V2 anymore. https://github.com/NginxProxyManager/nginx-proxy-manager/discussions/1202
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Mar 24, 2024):

Issue is now considered stale. If you want to keep it open, please comment 👍

<!-- gh-comment-id:2016661934 --> @github-actions[bot] commented on GitHub (Mar 24, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@HomemadeAdvanced commented on GitHub (Mar 25, 2024):

Is still an issue.

<!-- gh-comment-id:2017398878 --> @HomemadeAdvanced commented on GitHub (Mar 25, 2024): Is still an issue.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@jjmerri commented on GitHub (Nov 11, 2024):

why does reloading cause unavailability? I wouldn't care about this hourly check if it wasn't causing outages.

<!-- gh-comment-id:2468439228 --> @jjmerri commented on GitHub (Nov 11, 2024): why does reloading cause unavailability? I wouldn't care about this hourly check if it wasn't causing outages.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@kramttocs commented on GitHub (Nov 30, 2024):

So if it's checking every hour, I only need to open port 80 on my router, let's say as an example, for a period of 2hrs once a week, right?

Just thinking it'd be nice to not have port 80 open on the router if it isn't needed 24/7.

<!-- gh-comment-id:2508784451 --> @kramttocs commented on GitHub (Nov 30, 2024): So if it's checking every hour, I only need to open port 80 on my router, let's say as an example, for a period of 2hrs once a week, right? Just thinking it'd be nice to not have port 80 open on the router if it isn't needed 24/7.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@BuckinghamIO commented on GitHub (Jan 8, 2025):

5 years and no update on something that really is so very simple...

This is causing me issues now as the reload knocks off the home assistant app it seems.

<!-- gh-comment-id:2578489607 --> @BuckinghamIO commented on GitHub (Jan 8, 2025): 5 years and no update on something that really is so very simple... This is causing me issues now as the reload knocks off the home assistant app it seems.
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@kramttocs commented on GitHub (Jan 8, 2025):

5 years and no update on something that really is so very simple...

This is causing me issues now as the reload knocks off the home assistant app it seems.

Are you on the latest? Pretty sure the reload part was addressed with: github.com/NginxProxyManager/nginx-proxy-manager@1be87f48c1

<!-- gh-comment-id:2578779814 --> @kramttocs commented on GitHub (Jan 8, 2025): > 5 years and no update on something that really is so very simple... > > This is causing me issues now as the reload knocks off the home assistant app it seems. Are you on the latest? Pretty sure the reload part was addressed with: https://github.com/NginxProxyManager/nginx-proxy-manager/commit/1be87f48c156fdbbe981d3d5ff73758f2718c93c
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@jkwhar commented on GitHub (May 27, 2025):

I'm having the issue on 2.12.3. Current cert expiration is until July 15.

[5/27/2025] [4:24:27 PM] [SSL ] › ℹ info Renewing SSL certs expiring within 30 days ...
[5/27/2025] [4:24:27 PM] [SSL ] › ℹ info Completed SSL cert renew process
[5/27/2025] [5:24:27 PM] [SSL ] › ℹ info Renewing SSL certs expiring within 30 days ...
[5/27/2025] [5:24:27 PM] [SSL ] › ℹ info Completed SSL cert renew process
[5/27/2025] [6:24:27 PM] [SSL ] › ℹ info Renewing SSL certs expiring within 30 days ...
[5/27/2025] [6:24:27 PM] [SSL ] › ℹ info Completed SSL cert renew process

<!-- gh-comment-id:2914397146 --> @jkwhar commented on GitHub (May 27, 2025): I'm having the issue on 2.12.3. Current cert expiration is until July 15. [5/27/2025] [4:24:27 PM] [SSL ] › ℹ info Renewing SSL certs expiring within 30 days ... [5/27/2025] [4:24:27 PM] [SSL ] › ℹ info Completed SSL cert renew process [5/27/2025] [5:24:27 PM] [SSL ] › ℹ info Renewing SSL certs expiring within 30 days ... [5/27/2025] [5:24:27 PM] [SSL ] › ℹ info Completed SSL cert renew process [5/27/2025] [6:24:27 PM] [SSL ] › ℹ info Renewing SSL certs expiring within 30 days ... [5/27/2025] [6:24:27 PM] [SSL ] › ℹ info Completed SSL cert renew process
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@dragonfly4 commented on GitHub (Jun 23, 2025):

This is still running every hour and causing my Docker container to hang. Certificate expires on September 15, 2025.

github.com/NginxProxyManager/nginx-proxy-manager@f327c1e825/backend/internal/certificate.js (L34)

[6/23/2025] [11:43:47 AM] [SSL ] › ℹ info Renewing SSL certs expiring within 30 days ...
[6/23/2025] [11:43:47 AM] [SSL ] › ℹ info Completed SSL cert renew process

<!-- gh-comment-id:2996072550 --> @dragonfly4 commented on GitHub (Jun 23, 2025): This is still running every hour and causing my Docker container to hang. Certificate expires on September 15, 2025. https://github.com/NginxProxyManager/nginx-proxy-manager/blob/f327c1e825f3049309edbdbe3c0ebd423b51211d/backend/internal/certificate.js#L34 [6/23/2025] [11:43:47 AM] [SSL ] › ℹ info Renewing SSL certs expiring within 30 days ... [6/23/2025] [11:43:47 AM] [SSL ] › ℹ info Completed SSL cert renew process
kerem commented 2026-02-26 06:33:28 +03:00
Author
Owner
Copy link

@Dominic-Preap commented on GitHub (Dec 9, 2025):

Is there any way to bypass on that?

<!-- gh-comment-id:3630386445 --> @Dominic-Preap commented on GitHub (Dec 9, 2025): Is there any way to bypass on that?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
dependabot/npm_and_yarn/backend/liquidjs-10.25.7
dependabot/npm_and_yarn/frontend/prod-minor-updates-2a16bf3987
dependabot/npm_and_yarn/frontend/dev-patch-updates-754666cf41
dependabot/npm_and_yarn/backend/basic-ftp-5.3.0
dependabot/npm_and_yarn/test/follow-redirects-1.16.0
dependabot/npm_and_yarn/test/axios-1.15.0
dependabot/npm_and_yarn/frontend/lodash-4.18.1
dependabot/npm_and_yarn/backend/lodash-4.18.1
dependabot/npm_and_yarn/test/lodash-4.18.1
dependabot/npm_and_yarn/frontend/vite-7.3.2
dependabot/npm_and_yarn/backend/prod-minor-updates-5ec19a7f21
dependabot/npm_and_yarn/frontend/lodash-es-4.18.1
dependabot/npm_and_yarn/frontend/happy-dom-20.8.9
dependabot/npm_and_yarn/backend/path-to-regexp-8.4.0
dependabot/npm_and_yarn/frontend/picomatch-4.0.4
dependabot/npm_and_yarn/backend/picomatch-2.3.2
dependabot/npm_and_yarn/frontend/yaml-1.10.3
dependabot/npm_and_yarn/test/flatted-3.4.2
dependabot/npm_and_yarn/test/tar-7.5.11
dependabot/npm_and_yarn/frontend/immutable-5.1.5
master
dependabot/npm_and_yarn/test/glob-10.5.0
dependabot/npm_and_yarn/frontend/mdast-util-to-hast-13.2.1
dependabot/npm_and_yarn/test/form-data-4.0.4
v3-abandoned
bump-freedns
openidc
ssl-passthrough-hosts
static-content
v2.14.0
v2.13.7
v2.13.6
v2.13.5
v2.13.4
v2.13.3
v2.13.2
v2.13.1
v2.13.0
v2.12.6
v2.12.5
v2.12.4
v2.12.3
v2.12.2
v2.12.1
v2.12.0
v2.11.3
v2.11.2
v2.11.1
v2.11.0
v2.10.4
v2.10.3
v2.10.2
v2.10.1
v2.10.0
v2.9.22
v2.9.21
v2.9.20
v2.9.19
v2.9.18
v2.9.17
v2.9.16
v2.9.15
v2.9.14
v2.9.13
v2.9.12
v2.9.11
v2.9.10
v2.9.9
v2.9.8
v2.9.7
v2.9.6
v2.9.5
v2.9.4
v2.9.3
v2.9.2
v2.9.1
v2.9.0
v2.8.1
v2.8.0
v2.7.3
v2.7.2
v2.7.1
v2.7.0
v2.6.2
v2.6.1
v2.6.0
v2.5.0
v2.4.0
v2.3.1
v2.3.0
v2.2.4
v2.2.3
v2.2.2
v2.2.1
v2.2.0
v2.1.2
v2.1.1
v2.1.0
2.0.14
2.0.13
2.0.12
2.0.11
2.0.10
2.0.9
2.0.8
2.0.7
2.0.6
2.0.5
2.0.4
2.0.3
2.0.2
2.0.0
v2.0.0
1.1.2
1.1.1
1.0.1
Labels
Clear labels   
awaiting feedback

   
bug

   
cannot reproduce

   
dns provider request

   
duplicate

   
enhancement

   
enhancement

   
enhancement

   
good first issue

   
help wanted

   
invalid

   
need more info

   
no certbot plugin available

   
product-support

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
stale

   
troll

   
upstream issue

   
v2

   
v2

   
v2

   
v3

   
wontfix
No labels
awaiting feedback
bug
cannot reproduce
dns provider request
duplicate
enhancement
enhancement
enhancement
good first issue
help wanted
invalid
need more info
no certbot plugin available
product-support
pull-request
question
stale
troll
upstream issue
v2
v2
v2
v3
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nginx-proxy-manager-NginxProxyManager#573
No description provided.