--force-renewal CLI option - renewing a certificate before it's due

1

Hey everyone

I’ve found a few questions similar to this but they all seem to pre-date the --force-renewal option in the Certify CLI

Basically, my intention is to attempt to renew certificates every 4 weeks, so that if it fails, there is still time for a second attempt before my monitoring yells that we have 2 weeks until the cert expires.

My solution was a scheduled task every 4th Sunday to run the following:

certify renew --force-renewal
certify deploy xxx
certify deploy xxx

When I checked recently the two deployment tasks were running fine but they weren’t getting any content because the renewal wasn’t happening.

Manually testing now I do certify renew --force-renewal on its own and it says 0 certificates renewed.

Release notes say:

  • certify renew : renew certificates for all auto renewed managed sites, if they are due or have not yet been requested.
  • certify renew --force-renewal : As above but perform renewal for all auto renewed certificates even if they are not yet due.
    But it looks like it still isn’t forcing a certificate to renew until it’s due.

Have I just misunderstood the intention of that command?

Should I go with what I’ve read on another post, and just disable all certify services, set auto renewal interval to, say, 1 day, and then have my scheduled task enable the service, run the renewal, and then disable the service?
Neater would be nicer :slight_smile:

Thanks
KH

2

HI, you are fighting against the built in certificate renewal system and the CLI commands are absolutely for use as a last resort or for specific limited cases.

By default the Certify background service takes care of all renewals automatically, it does this according to the renewal interval set under Settings. Typically, this renewal is every 30 days - but your certificate won’t expire for 90 days (the Let’s Encrypt cert lifetime). We default to 30 days to give new users time to sort out any renewal issues they may have first time round. By default the Certify API will notify you (via the account email set under Settings > Certificate Authorities) after the first few attempts to renew have failed.

Do you have a specific reason or not using the default Certify renewal system?

If you have a special requirement to only deploy your cert at specific times to non-IIS services, you should use the Deployment Tasks system and a Manual deployment trigger, which you can then run manually or via a scheduled tasks to apply the latest version of the cert.

3

Hi mate, only for lack of a better understanding of how to do it.

Basically, I want renewal and install to only happen at, say, 3am on a Sunday.

I haven’t figured out how to run deployment tasks on command any have them actually pick up the certificate, only if the renewal happens at the same time (I’ve been using a PS script to install the cert for all RDS roles, but it passes empty variables if it happens after)

And the RDS Deployment built in task doesn’t actually install the certificate.

I suppose I could do a 28 day renewal interval, but I want a way to make sure that NOTHING is done except in that very narrow window, hence wanting to be able to force the renewal at that time :slight_smile:

4

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:

Request/Renewal
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.

Deployment
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

5

This is incredibly helpful information.

Thanks mate :ok_hand: I will re-jig - cheers :slight_smile:

KH

6

Thanks again
I think I’ve got my new procedure -
Basically, script will be to check local cert store for the certificate matching “[Certify]” with the latest expiry date. If it’s not already installed, then install it.

Only other thing I’d ask of you please:
Is there a way to stop the IIS binding automatically updating and is the IIS binding automation just what is outlined here:

Just hoping to try and minimise the amount that gets done outside my window :slight_smile:

7

Currently the only IIS binding automation we offer is part of the standard deployment and is not done as a task, however I can assure you it is robust and is used successfully hundreds of thousands of times per day :slight_smile:

IIS binding is a little more complicated that the example script because it goes via the IIS Administration API and affects the applicationhost config (xml). IIS updates are performed as atomic transactions via the IIS admin API, which means changing your cert doesn’t interrupt requests. I can only suggest that you try this out for yourself to gain confidence in the process.

If Deployment mode is set to ‘Auto’, ‘Single Site’ or ‘Certificate Store’ you should never have to check if the cert is in the store, because the thumbprint we pass your script is of the cert that was stored. Checking based on latest date and friendly name is a little haphazard compared to just using the thumbprint we give you already but if you’re happy how it is then it’s no problem.

If I were you I’d use the built in auto deployment for IIS, then use your own script Task for the RDP cert part, running that during your maintenance window. The server is happy to have different versions of the cert bound to different ports, so that’s not an issue.

Certify will take care of certificate store cleanup itself, by default it will clean up [Certify] certs which have expired, so although your store will have multiple certs they do eventually get cleaned up. You can choose more aggressive cleanup options under settings but there no real advantage to that.