+1 This would be a great enhancement!
At the moment I have to change every 60+ days the Certs of 30 containers manually when my LE Cert is renewed.
I use docker Linuxserver/swag to renew my wildcard LE Cert and that has to be imported every-time on a renewal for every container.

+1

as a "workaround" i managed to update the cert files within the container itself and restarted nginx. this works for my sites. only disadvantage: NPM doesn't (and can't) know the new expiration date and shows it as overdue. but: you don't have to update all your reverse proxys and services.

I have the same issue, when my wildcard cert is expiring.
I don't want to manually edit all my domain entries.

A "Renew Custom Cert" would be a pretty nice feature

+1

as a "workaround" i managed to update the cert files within the container itself and restarted nginx. this works for my sites. only disadvantage: NPM doesn't (and can't) know the new expiration date and shows it as overdue. but: you don't have to update all your reverse proxys and services.

Would you like to share your workaround?

@BobWs as i wrote, i updated the cert files within the container. as the filesystem is a mounted volume (folder?) to keep everything persistent, this was quite easy.

i restarted the container and it started again, now using the new certificate.

as i mentioned: only the disadvantage is, that it still shows the old expiration date in the UI

i think this has to do with the fact that the data is stored in a database and it is only updated when going through the UI.

+1 This would be a great enhancement!
I have more than 100 Hosts.
For now the solution of spcqike works.

I confirm that this would be of great help. I have a wildcard certificate (on a private network with no public DNS, so no Let's Encrypt possible) and I have 100+ hosts to update, it is a slow process! Thank you :)

Same routine every 3 months. Nothing new ?

i know this is a thread necro, but I'm curious if any progress has been made on this front.
I use a wildcard letsencrypt certificate, using a domain registrar that doesn't support automation, in order to obfuscate my subdomains. It is quite frustrating having to "rebuild" all the certificate configurations for all my subdomains byu hand.

I am going to explore the solution that @spcqike has provided. but in the meantime, I'd like to give my +1 to this enhancement request.

The @spcqike approach works for me, so I say give it try.

The current mounting workaround is OK... but it would be beneficial to have a feature in the UI that allows for updating an existing certificate by re-uploading new certificate files without removing the existing one (associations with hosts are conserved). This enhancement would empower the less technical members of my team to update certificates independently, especially considering we have 50 hosts using the same wildcard to update individually.

Big +1

This feature request was posted 2 years ago, so don't get your hopes up for it to change within a reasonable period!
I guess it's is a very low priority feature to implement for the developers.

as its open source, everyone who can code can do so and open a pull request.

especially considering we have 50 hosts using the same wildcard to update individually.

in this case i would think about a central storage location, where all hosts read the same file. or at least a script that keeps the certificate updated on every host automatically. updating 50 hosts in a webUI manually is .... not practical.

I've got the same Problem. I solved it with the workaround from @spcqike.
I have also found a workaround for the problem with the expiration date. To do this, simply change the expires_on entry from your certificate in the table certificates in the NPM database. I use MariaDB and have set the expiration date to that of the new certificate. You can also set it to any other date you want.
You can do this either via the console or via phpMyAdmin, which is much easier.

Based on @spcqike answer:

After you update the CRT file. Add a dummy domain with the new CRT.
Then download locally the database.sqlite file from your docker container.
Open it on your machine with a sqlite editor
Go to certificate table and view the rows
Edit the dummy row you added before and note down the content of modified_on, expires_on and meta.
Now edit the actual row of the domain you would like to modify, and copy paste the data we extracted on previous step
Delete the dummy row and save the changes
Copy the new/modified database.sqlite file back to the container and restart it

Here's your edit "button" :)

+1 for a replace feature to select either all new or only the new cert (while keeping the key). Would make custom cert updates easier.

An upload/edit via textarea (input base64) would be nice as well.

+1

A workround works form me:
nginx_manager_1 is your container name of nginx-proxy-manager.
docker volumes: /root/data:/data

Using the acme.sh script to automatically install the certs file:
acme.sh xxxxxxxxxx --key-file /root/data/custom_ssl/npm-2/privkey.pem --fullchain-file /root/data/custom_ssl/npm-2/fullchain.pem --reloadcmd "docker exec nginx_manager_1 nginx -s reload"

or you can manually do it with command everything 3 month:
docker exec nginx_manager_1 nginx -s reload;

I have also faced the same issue, and I managed to come up with a solution PR #4425.

This is my solution,
Connect to SQLite3 and update proxy_host to use the new host.
Find the ID of the new certificate.

`sqlite3 data/database.sqlite
SQLite version 3.22.0 2018-01-22 18:45:57
Enter ".help" for usage hints.
sqlite> SELECT id,nice_name,domain_names FROM certificate;

9 is the new certificate ID.
2 is the old certificate ID.

UPDATE proxy_host SET certificate_id = 9 WHERE certificate_id = 2;
restart service
`