Thanks, so there’s two aspects to consider:
1 - getting a fresh certificate to play with
2 - using the certificate (deployment)
Some users do choose to stop the certify service and start it again during a maintenance window, it’s possible to work that way but it’s not supported or recommended.
If using that strategy you could just uncheck the Certificate > Advanced > General Options > Enable Auto Renewal option. To then perform your renewal you would have to start the Certify service (or just always have it running doing nothing) and call
certify renew --force-renew-all - which would in turn attempt the renewal.
We should introduce a new
--renew-all-due flag to renew anything that’s due whether it’s set to auto renew or not. I’ll add that for the next release, that way you could set the renewal interval setting to 5 days (or less) and then the renewal will always be due whenever you call the renewal command.
In terms of how renewals are supposed to work:
Currently we don’t have supported way you can control getting the certificate (step 1), other than clicking ‘Request Certificate’ in the UI (you could set the certificate to not auto renew, if you want to fully control renewal this way).
This is because renewal involves placing a new certificate order, performing validation (which may be via http validation or dns validation), then requesting the certificate. Once we have the cert then by default we auto deploy it, but you can opt to either just store it on disk or install it in the certificate store (along with the previous version of the cert).
All of these steps can fail normally (LE goes down, your connection drops, it’s friday afternoon etc) so our service is optimised to handle the failure and gracefully retry the certificate order. Currently we just don’t have a built-in way to give you direct control of that process via the command line.
The service is optimised to be able to request/renew hundreds or even thousands of certificates in a managed way. Forcing renewal of many certificates can/will result in Let’s Encrypt API rate limits, so that’s why it’s avoided. If you only attempt renewal within a narrow window there is a real chance that the process will not be successful and you’ll then have to wait until next time to try again, so only trying once a month isn’t really enough.
Once we have the cert as mentioned the cert will normally be in the local machine certificate store, as will your old cert. At that point your existing cert is unaffected and it can sit like that until the old cert expires, you just happen to also have a new cert waiting ready to be used.
By default as mentioned we perform auto deployment (save it to disk, import it into the local certificate store and apply it to any relevant known IIS bindings). This is controlled on the Deployment tab and can be previewed using the Preview tab.
After the standard deployment stage we have optionally deployment Tasks, these normally run immediately after we have successfully stored the new certificate, but you can set the trigger to Manual and decide how/when to run the task yourself. You can customise the task and run your own scripts.
It sounds like you have experimented with the deployment tasks already. You are correct that the RDS deployment task does not install the cert (to the store) as this should already have been done, there is also a Deploy to Local Store task you can run first (not that task order is top to bottom and the order is drag & drop).
You can see the source of our basic RDS related tasks here: https://github.com/webprofusion/certify-plugins/tree/master/src/DeploymentTasks/Core/Providers/Assets - whether it works for your scenario will depend on several factors and you may well prefer to use a custom script.
When you set a Deployment Task to Manual trigger, the UI will show you the command that you’d need to run to trigger the task, this needs to run (from
C:\Program Files\CertifyTheWeb working directory) as a user who can normally use the Certify app, so that it has permission to access the Certify service API, and the Certify service must already be running. You can also just manually run the task during a maintenance window by hitting the play button.
If you are calling a powershell script it’s an optional checkbox to pass the Result object in as a parameter, this provides an object with properties that you can use in your script. https://docs.certifytheweb.com/docs/script-hooks#scripting-basics