Bug #9502
closed
ACME's XMLRPC restart of remote webgui sometimes retains old certificates
0%
Description
I have two hosts using HA syncing to push the certificate store from host1 (primary) to host2 (backup). ACME renewal runs only on host1, which is configured to use XMLRPC to restart the webconfigurator on host2 as documented.
Recently we had an expired cert issue appear on host2. Restarting the webconfigurator via SSH fixed this immediately, as it appeared the certificates had transferred properly. In testing, I did a forced renewal and duplicated this result. pfSense cert manager on host2 showed the new certificate was in place, and the logs showed the XMLRPC request to restart had been received and acted on. Running "reloadcmd.sh" a second time resolved this and the new certificate was in use by host2.
My speculation here is that the restart request is hitting host2 before the XMLRPC sync of the certificate store is complete. Is it possible to check sync status before requesting restart? Should there be an option to delay the restart request by a few seconds? Is there some neat solution other than just having a cron job to restart the webconfigurator once a week or so?
Updated by Jim Pingle about 5 years ago
- Status changed from New to Not a Bug
That isn't possible as the code that does the sync comes before the reload, and the sync process blocks. I haven't seen this on any of the ACME HA setups I have, and looking at the code, I don't see how it could happen unless there is some other contributing factor in your config or environment.
The write config at https://github.com/pfsense/FreeBSD-ports/blob/devel/security/pfSense-pkg-acme/files/usr/local/pkg/acme/acme_command.sh#L46 triggers the config sync and then after that, the remote command triggers at https://github.com/pfsense/FreeBSD-ports/blob/devel/security/pfSense-pkg-acme/files/usr/local/pkg/acme/acme_command.sh#L68
Please post on the Netgate Forum or the pfSense Subreddit to gather more information before opening an issue.
Updated by Jim Pingle about 5 years ago
I am not sure it would be related to what you saw, but you might give the newest version of the ACME package a try (0.5.7_1).
Updated by Mike Barnes about 5 years ago
Jim Pingle wrote:
I am not sure it would be related to what you saw, but you might give the newest version of the ACME package a try (0.5.7_1).
Back on that site today, no config changed other than update to the ACME package, and it now works exactly as intended - at some point when I get some leisure time I'll roll back to the previous version and verify what's happening but after digging through everything last week, I'm pretty convinced the sleep() call is all we needed here. Thanks!