[GH-ISSUE #4288] [BUG] Deleting a certificate without detaching it from the hosts breaks NPM #2760

Open
opened 2026-02-26 07:36:42 +03:00 by kerem · 5 comments
Owner

Originally created by @Grishkaone on GitHub (Jan 10, 2025).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/4288

Describe the bug
I use NPM on a Rasberry Pi. Data is stored in 2 volumes: one for /data and another for /etc/letsencrypt.
I have 13 hosts which are all sub-domains of my main domain.
I generate a Let's Encrypt wildcard certificate with a DNS challenge.
All this worked very well.

I recently changed registrar for my domain. Once the migration was completed with the DNS zones up and running, I had to change the method of generating the wildcard certificate (change of API and identifier).

It's not possible to edit this information in NPM. I therefore deleted the certificate, with a view to creating a new one. The deletion was carried out without error. Afterwards, it was impossible to do anything in the back office. I was unlocated and couldn't relocate. I restarted the container, but nothing changed.

There's an error nginx proxy manager nginx: [emerg] cannot load certificate: what I understand is that the 13 hosts that are still attached to the certificate are trying to load it without success since it's no longer there. I no longer have access to the BO to detach hosts from the certificate.

To get back in control, here are the steps I took:

  1. Connect to the container console
  2. Open /data/nginx/proxy_host/
  3. Delete all *.conf files

Then I was able to reconnect to the BO, the hosts are still there, but no certificates are linked to them.
I could set up my new certificate and attach it to each host one by one. The *.conf files were regenerated at this point.

Nginx Proxy Manager Version
2.11.3

To Reproduce
On a configuration with several hosts attached to a wildcard certificate.

  1. Open the SSL Certificates tab
  2. Click on the menu to the right of the certificate and select Delete.
  3. Confirm deletion.
    NPM becomes unusable.

Expected behavior
I can see several solutions.

  1. Prohibit deletion of a certificate attached to an active host. Add a warning when deleting the certificate to indicate that x hosts are bound to this certificate and not allow deletion until they have been manually detached.
  2. Automate the process. A message similar to solution 1, but indicating that deletion will automatically detach the certificate from each host beforehand, with a checkbox to indicate agreement.

Screenshots
No screenshot, sorry, everything work fine now.

Operating System
Linux 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
Debian version : 11.11

Additional context
I'm in no hurry to reproduce this problem. I'm not in a position to say whether the fact that it's a wildcard certificate is relevant to causing the bug.
There's another solution that I haven't tried: restore the certificates from a backup of the volume, which should work to restore a functional back office.

Originally created by @Grishkaone on GitHub (Jan 10, 2025). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/4288 **Describe the bug** I use NPM on a Rasberry Pi. Data is stored in 2 volumes: one for `/data` and another for `/etc/letsencrypt`. I have 13 hosts which are all sub-domains of my main domain. I generate a Let's Encrypt wildcard certificate with a DNS challenge. All this worked very well. I recently changed registrar for my domain. Once the migration was completed with the DNS zones up and running, I had to change the method of generating the wildcard certificate (change of API and identifier). It's not possible to edit this information in NPM. I therefore deleted the certificate, with a view to creating a new one. The deletion was carried out without error. Afterwards, it was impossible to do anything in the back office. I was unlocated and couldn't relocate. I restarted the container, but nothing changed. There's an error `nginx proxy manager nginx: [emerg] cannot load certificate`: what I understand is that the 13 hosts that are still attached to the certificate are trying to load it without success since it's no longer there. I no longer have access to the BO to detach hosts from the certificate. To get back in control, here are the steps I took: 1. Connect to the container console 2. Open `/data/nginx/proxy_host/` 3. Delete all `*.conf` files Then I was able to reconnect to the BO, the hosts are still there, but no certificates are linked to them. I could set up my new certificate and attach it to each host one by one. The `*.conf` files were regenerated at this point. **Nginx Proxy Manager Version** 2.11.3 **To Reproduce** On a configuration with several hosts attached to a wildcard certificate. 1. Open the **SSL Certificates** tab 2. Click on the menu to the right of the certificate and select **Delete**. 3. Confirm deletion. NPM becomes unusable. **Expected behavior** I can see several solutions. 1) **Prohibit deletion of a certificate attached to an active host**. Add a warning when deleting the certificate to indicate that x hosts are bound to this certificate and not allow deletion until they have been manually detached. 2) **Automate the process**. A message similar to solution 1, but indicating that deletion will automatically detach the certificate from each host beforehand, with a checkbox to indicate agreement. **Screenshots** No screenshot, sorry, everything work fine now. **Operating System** Linux 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" Debian version : 11.11 **Additional context** I'm in no hurry to reproduce this problem. I'm not in a position to say whether the fact that it's a wildcard certificate is relevant to causing the bug. There's another solution that I haven't tried: restore the certificates from a backup of the volume, which should work to restore a functional back office.
Author
Owner

@dogshapedangel commented on GitHub (Feb 14, 2025):

I just ran into this issue as well.

Deleted some certificates from my Let's Encrypt store via the GUI, suddenly the npm-2 certificate was missing and my entire installation was broken. Opted to start from scratch since it had only been spun up a few days ago.

While I'm sure folks don't do this often, this feels like a fairly major issue.

<!-- gh-comment-id:2658088641 --> @dogshapedangel commented on GitHub (Feb 14, 2025): I just ran into this issue as well. Deleted some certificates from my Let's Encrypt store via the GUI, suddenly the npm-2 certificate was missing and my entire installation was broken. Opted to start from scratch since it had only been spun up a few days ago. While I'm sure folks don't do this often, this feels like a fairly major issue.
Author
Owner

@szavadschi commented on GitHub (Feb 27, 2025):

I've found a temporary solution to this issue. You can manually edit the configuration file of the affected host. The file is located at data/nginx/proxy_host/xx.conf (replace 'xx' with your Proxy Host #).

Remove the following lines:

listen 443 ssl http2;

and

  # Let's Encrypt SSL
  include conf.d/include/letsencrypt-acme-challenge.conf;
  include conf.d/include/ssl-ciphers.conf;
  ssl_certificate /etc/letsencrypt/live/npm-xx/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/npm-xx/privkey.pem;

After removing these lines, simply open the host's configuration in the GUI and click 'Save' without making any other changes. This should resolve the problem. Hopefully, this saves someone else the headache of starting over.

<!-- gh-comment-id:2687058843 --> @szavadschi commented on GitHub (Feb 27, 2025): I've found a temporary solution to this issue. You can manually edit the configuration file of the affected host. The file is located at `data/nginx/proxy_host/xx.conf` (replace 'xx' with your Proxy Host #). Remove the following lines: ``` listen 443 ssl http2; ``` and ``` # Let's Encrypt SSL include conf.d/include/letsencrypt-acme-challenge.conf; include conf.d/include/ssl-ciphers.conf; ssl_certificate /etc/letsencrypt/live/npm-xx/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/npm-xx/privkey.pem; ``` After removing these lines, simply open the host's configuration in the GUI and click 'Save' without making any other changes. This should resolve the problem. Hopefully, this saves someone else the headache of starting over.
Author
Owner

@kilrah commented on GitHub (Mar 25, 2025):

I have found the problem also exists even when the host is not supposed to be using the cert anymore.

  • Create a host with LE cert generation
  • Change the host to not use SSL, unassign the cert from the host
  • Delete the cert
  • NPM won't start.

Had to restore the cert from the previous day's backup, delete the host, then remove the cert files again (since it won't appear in the GUI again as it's been marked as deleted in the DB.

Also in general a missing cert should only affect the host, not prevent the whole container from starting.

<!-- gh-comment-id:2750522822 --> @kilrah commented on GitHub (Mar 25, 2025): I have found the problem also exists even when the host is not supposed to be using the cert anymore. - Create a host with LE cert generation - Change the host to not use SSL, unassign the cert from the host - Delete the cert - NPM won't start. Had to restore the cert from the previous day's backup, delete the host, then remove the cert files again (since it won't appear in the GUI again as it's been marked as deleted in the DB. Also in general a missing cert should only affect the host, not prevent the whole container from starting.
Author
Owner

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

The bug still persists. Is anyone working on this?

<!-- gh-comment-id:2996195068 --> @KristopherMackowiak commented on GitHub (Jun 23, 2025): The bug still persists. Is anyone working on this?
Author
Owner

@gabrielecabrini commented on GitHub (Nov 11, 2025):

I also have the same probem, I've got to manually edit the proxy confs and remove the ssl part referencing old (deleted) certs

<!-- gh-comment-id:3515340838 --> @gabrielecabrini commented on GitHub (Nov 11, 2025): I also have the same probem, I've got to manually edit the proxy confs and remove the ssl part referencing old (deleted) certs
Sign in to join this conversation.
No milestone
No project
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#2760
No description provided.