[GH-ISSUE #49] Cert removed, Update failed #37

Closed
opened 2026-02-26 21:31:25 +03:00 by kerem · 5 comments
Owner

Originally created by @Mogikan on GitHub (Nov 2, 2020).
Original GitHub issue: https://github.com/ridercz/AutoACME/issues/49

I must say that your project is great and want to say thank you. But there is a problem with maintenance algorithm.
A day ago I reached cert limit per group domain (I moved subdomain to another hosting and had problems with new cert), but my main domain had a valid cert. It automatically do maintenance every day.
It deleted my valid cert (which could still work for 30 days as far as I remember) and failed to acquire new cert. The limit is reset every 7 days and I had nothing to do, but to buy a commercial cert.
Is it possible not to delete cert (download cert with a different name) and if it fails just do nothing instead of deleting cert?

Originally created by @Mogikan on GitHub (Nov 2, 2020). Original GitHub issue: https://github.com/ridercz/AutoACME/issues/49 I must say that your project is great and want to say thank you. But there is a problem with maintenance algorithm. A day ago I reached cert limit per group domain (I moved subdomain to another hosting and had problems with new cert), but my main domain had a valid cert. It automatically do maintenance every day. It deleted my valid cert (which could still work for 30 days as far as I remember) and failed to acquire new cert. The limit is reset every 7 days and I had nothing to do, but to buy a commercial cert. Is it possible not to delete cert (download cert with a different name) and if it fails just do nothing instead of deleting cert?
kerem closed this issue 2026-02-26 21:31:25 +03:00
Author
Owner

@ridercz commented on GitHub (Nov 2, 2020):

Sorry, but the description is so confusing that I can't figure out your problem.

<!-- gh-comment-id:720448062 --> @ridercz commented on GitHub (Nov 2, 2020): Sorry, but the description is so confusing that I can't figure out your problem.
Author
Owner

@avonwyss commented on GitHub (Nov 2, 2020):

I also had certs failing to renew for some reason, but the currently valid cert was never deleted by AutoACME, so that I also cannot figure out what happened. Do you have logs showing the problem?

And - as always - it's good practice to have regular (for instance daily) backups of your servers, so that you can restore in the case of some data loss. This would have allowed you to restore the deleted cert.

<!-- gh-comment-id:720452292 --> @avonwyss commented on GitHub (Nov 2, 2020): I also had certs failing to renew for some reason, but the currently valid cert was never deleted by AutoACME, so that I also cannot figure out what happened. Do you have logs showing the problem? And - as always - it's good practice to have regular (for instance daily) backups of your servers, so that you can restore in the case of some data loss. This would have allowed you to restore the deleted cert.
Author
Owner

@Mogikan commented on GitHub (Nov 3, 2020):

Thanks for an idea, I asked our admin and there was a full snapshot of the Server with cert which was deleted. And I was able to reproduce the issue.

image
image
C:\CertStore\AutoACME>autoacme.exe maintenance 10:37 AM
Altairis AutoACME Manager version 1.6.2.0
Copyright c Michal A. Valásek - Altairis and contributors, 2017-2019
www.autoacme.net | www.rider.cz | www.altairis.cz

Reading configuration from 'C:\CertStore\AutoACME\autoacme.json'...OK
Loading hosts expiring in 30 days...OK, 1 hosts to renew
Accepting TOS at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf...OK
Host mobidb.mobi expired 44 days ago (Sunday, September 20, 2020)
Testing authorization:
Writing challenge to C:\InetPub\wwwroot\AutoAcme\probe_fb60a023-a360-47a9-ada6-c0d9fe41da7a...OK
Testing HTTP challenge:
Preparing request to http://mobidb.mobi/.well-known/acme-challenge/probe_fb60a023-a360-47a9-ada6-c0d9fe41da7a...OK
Getting response...OK
Reading response...OK
OK: Status code 200
OK: Content-Type header
OK: Expected response received
Deleting challenge from C:\InetPub\wwwroot\AutoAcme\probe_fb60a023-a360-47a9-ada6-c0d9fe41da7a...OK
Preparing order
Renewal failed!
Fail to load resource from 'https://acme-v02.api.letsencrypt.org/acme/new-order'.
urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates already issued for exact set of domains: mobidb.mo
bi: see https://letsencrypt.org/docs/rate-limits/
Loading hosts expired at least 30 days ago...OK, 1 hosts to purge:
Host mobidb.mobi expired 43 days ago (Sunday, September 20, 2020)
Deleting from database...OK
Deleting files:
Deleting file C:\CertStore\PFX\mobidb.mobi.pfx...OK
Saving configuration to 'C:\CertStore\AutoACME\autoacme.json'...OK

Furthermore, host is also deleted from json file.

<!-- gh-comment-id:720887401 --> @Mogikan commented on GitHub (Nov 3, 2020): Thanks for an idea, I asked our admin and there was a full snapshot of the Server with cert which was deleted. And I was able to reproduce the issue. ![image](https://user-images.githubusercontent.com/5044182/97947635-75ab0280-1dc0-11eb-9ccd-b3ec936dc37a.png) ![image](https://user-images.githubusercontent.com/5044182/97947649-8491b500-1dc0-11eb-84e1-b13ea7511a35.png) C:\CertStore\AutoACME>autoacme.exe maintenance 10:37 AM Altairis AutoACME Manager version 1.6.2.0 Copyright c Michal A. Valásek - Altairis and contributors, 2017-2019 www.autoacme.net | www.rider.cz | www.altairis.cz Reading configuration from 'C:\CertStore\AutoACME\autoacme.json'...OK Loading hosts expiring in 30 days...OK, 1 hosts to renew Accepting TOS at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf...OK Host mobidb.mobi expired 44 days ago (Sunday, September 20, 2020) Testing authorization: Writing challenge to C:\InetPub\wwwroot\AutoAcme\probe_fb60a023-a360-47a9-ada6-c0d9fe41da7a...OK Testing HTTP challenge: Preparing request to http://mobidb.mobi/.well-known/acme-challenge/probe_fb60a023-a360-47a9-ada6-c0d9fe41da7a...OK Getting response...OK Reading response...OK OK: Status code 200 OK: Content-Type header OK: Expected response received Deleting challenge from C:\InetPub\wwwroot\AutoAcme\probe_fb60a023-a360-47a9-ada6-c0d9fe41da7a...OK Preparing order Renewal failed! Fail to load resource from 'https://acme-v02.api.letsencrypt.org/acme/new-order'. urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates already issued for exact set of domains: mobidb.mo bi: see https://letsencrypt.org/docs/rate-limits/ Loading hosts expired at least 30 days ago...OK, 1 hosts to purge: Host mobidb.mobi expired 43 days ago (Sunday, September 20, 2020) Deleting from database...OK Deleting files: Deleting file C:\CertStore\PFX\mobidb.mobi.pfx...OK Saving configuration to 'C:\CertStore\AutoACME\autoacme.json'...OK Furthermore, host is also deleted from json file.
Author
Owner

@avonwyss commented on GitHub (Nov 3, 2020):

Based on the logs posted the database file (autoacme.json) and cert file were out of sync. Whenever a new cert is requested by AutoACME, the database should be updated with the expiry date of the certificate; only this information is used to determine which hosts to purge. This situation could for instance have happened if the new cert was manually copied into the folder.

Note that if your list of hosts does not frequently change, you may want to have AutoACME do only updates, not maintenance (note that maintenance equals to update and purge). This would avoid automatic deletion of hosts and certs altogether.

@ridercz AutoACME could maybe analyze the cert (pfx) to be renewed or deleted to ensure that its database is up-to-date before actually performing the action, what do you think? This would not add too much overhead but ensure that outdated database information does not cause unnecessary or unwanted (as in this case) operations to be performed.

<!-- gh-comment-id:720992835 --> @avonwyss commented on GitHub (Nov 3, 2020): Based on the logs posted the database file (autoacme.json) and cert file were out of sync. Whenever a new cert is requested by AutoACME, the database should be updated with the expiry date of the certificate; only this information is used to determine which hosts to purge. This situation could for instance have happened if the new cert was manually copied into the folder. Note that if your list of hosts does not frequently change, you may want to have AutoACME do only updates, not maintenance (note that maintenance equals to update and purge). This would avoid automatic deletion of hosts and certs altogether. @ridercz AutoACME could maybe analyze the cert (pfx) to be renewed or deleted to ensure that its database is up-to-date before actually performing the action, what do you think? This would not add too much overhead but ensure that outdated database information does not cause unnecessary or unwanted (as in this case) operations to be performed.
Author
Owner

@Mogikan commented on GitHub (Nov 3, 2020):

I see, the problem is caused by permissions. I didn't know that config is updated during maintenance. I thought it look at cert date not in the config file. My "certUpdateUser" used in scheduler only has access to PFX folder and not to ACME folder. Thanks for the tip to use renew instead of maintenance. I actually don't understand what's for to duplicate data which can be restored from cert file in the so called database. For me it looks like a config file which shouldn't change. It should change only when new host added/removed.

<!-- gh-comment-id:721013289 --> @Mogikan commented on GitHub (Nov 3, 2020): I see, the problem is caused by permissions. I didn't know that config is updated during maintenance. I thought it look at cert date not in the config file. My "certUpdateUser" used in scheduler only has access to PFX folder and not to ACME folder. Thanks for the tip to use renew instead of maintenance. I actually don't understand what's for to duplicate data which can be restored from cert file in the so called database. For me it looks like a config file which shouldn't change. It should change only when new host added/removed.
Sign in to join this conversation.
No labels
pull-request
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/AutoACME#37
No description provided.