Win-acme: --force switch broken in 2.1.6

[WouterTinus]

There is indeed a bug for renewals in 2.1.6.1. I have experienced this today when installing 2.1.6.1 cleanly on a new machine that never had win-acme on it prior to today 04/03/2020. It is a Server 2008 R2 machine with IIS 7.5 and only one website in place for Default Websites (option "N" can't be used from the main menu of win-acme because it doesn't find any IIS bindings on the IIS 7.5 machine - the error is displayed as: "No sites with host bindings have been configured in IIS. Add one in the IIS Manager or choose the plugin 'Manual input' instead."), so I have to use Manual method. The first creation of the SSL cert worked and it successfully bound itself to the single site HTTPS/443 binding with the proper cert showing. However, renewals with --force added would not work as it looked to be re-using the same Thumbprint ID for each renewal attempt. win-acme 2.1.6.1 is set to use these options:

• Plugin: SelfHosting - (Serve verification files from memory)
  CSR -----------------------------------------------------------------

• Plugin: RSA - (RSA key)
  Store -----------------------------------------------------------------

• Plugin: CertificateStore - (Windows Certificate Store)
  Installation -----------------------------------------------------------------

• Plugin: IIS - (Create or update https bindings in IIS)
  History -----------------------------------------------------------------

I was able to resolve this issue by overwriting the 2.1.6.1 files with 2.4.1.710 files (open win-acme.v2.1.4.710.x64.pluggable.zip and then extract and overwrite all existing files) as I read in the win-acme Release Notes that there were changes to the way renewals worked in 2.1.6.1 so that is why I went with 2.1.4 for the replacement version attempt since it is still a recent build from 02/04/2020.

To show the issue with 2.1.6.1 for IIS 7.5 here are the details of the renewals that occurred, in this case I only have one SSL cert in place:

1: 4/3/2020 8:41:57 PM - Success - Thumbprint 19EDE2DFDCD845962B465152BA89CF565
15D6492
2: 4/3/2020 9:54:43 PM - Success - Thumbprint 19EDE2DFDCD845962B465152BA89CF565
15D6492
3: 4/3/2020 10:05:22 PM - Success - Thumbprint 19EDE2DFDCD845962B465152BA89CF56
515D6492

The first run was the first time it created the SSL cert or it was the first time a normal renewal attempted to run (without --force added), the second run is the forced renewal by adding --force to the scheduled task and running the task manually, and the third was a normal renewal which was not due yet. You can see that all 3 times the renewal attempted to run it used the same Thumbprint ID. Then in the win-acme dated log it showed this for the force renewal attempt using v2.1.6.1:

2020-04-03 15:40:29.887 -07:00 [INF] Force renewing certificate for [Manual] builder.domainremoved.com
2020-04-03 15:40:30.231 -07:00 [INF] Authorize identifier: builder.domainremoved.com
2020-04-03 15:40:30.231 -07:00 [INF] Cached authorization result: valid
2020-04-03 15:40:30.262 -07:00 [INF] Authorize identifier: builder.domainremoved.com
2020-04-03 15:40:30.277 -07:00 [INF] Cached authorization result: valid
2020-04-03 15:40:30.309 -07:00 [WRN] Using cached certificate for [Manual] builder.domainremoved.com. To force issue of a new certificate within 1 days, delete the .pfx file from the CertificatePath or run with the --force switch. Be ware that you might run into rate limits doing so.
2020-04-03 15:40:30.309 -07:00 [INF] Store with CertificateStore...
2020-04-03 15:40:30.324 -07:00 [WRN] Certificate with thumbprint 15DDE2DFDCD845962B465152BA89CF56515D6492 is already in the store
2020-04-03 15:40:30.324 -07:00 [INF] Installing with IIS...
2020-04-03 15:40:30.402 -07:00 [INF] Committing 1 https binding changes to IIS
2020-04-03 15:40:30.418 -07:00 [INF] Next renewal scheduled at 2020/5/28 15:40:30
2020-04-03 15:40:30.433 -07:00 [INF] Renewal for [Manual] builder.domainremoved.com succeeded

The force renewal failed because it detected the same Thumbprint for the cert.

The issues are similar to what the resolution was for this post, I took that clue and rolled the version back from 2.1.6.1 to 2.1.4.710 and it solved my issue.
https://github.com/win-acme/win-acme/issues/692

To resolve this I extracted the files from v2.1.4.710 to my installed directory and overwrite all files. I then ran the scheduled task again, which has the --force command added to wacs.exe and when looking at the Renewal details inside wacs I could see that the newest renewal attempt using 2.1.4 had a different thumbprint ID compared to the older ones, and I after reloading the win-acme log I could see that it was not no longer stating that the thumbprint was the same and could not replace the cert to the binding. The new verbose log entry for the forced renewal attempt after downgrading from v2.1.6.1 to v2.1.4.710 shows that it did bind to IIS and completed everything successfully, with a new Thumbprint ID for that last attempt using 2.1.4.710, as seen here:

2020-04-03 15:44:05.918 -07:00 [INF] Adding certificate [Manual] builder.domainremoved.com @ 2020/4/3 15:43:59 to store My
2020-04-03 15:44:05.918 -07:00 [VRB] CN=builder.domainremoved.com - CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US (8F45F06308C6AD6D728CB9629C0710B4651866EC)
2020-04-03 15:44:05.933 -07:00 [DBG] Closing certificate store
2020-04-03 15:44:05.933 -07:00 [VRB] CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US - CN=DST Root CA X3, O=Digital Signature Trust Co. (E6A3B45B062D509B3382282D196EFE97D5956CCB) to store CA
2020-04-03 15:44:05.933 -07:00 [DBG] Closing store CA
2020-04-03 15:44:05.949 -07:00 [INF] Installing with IIS...
2020-04-03 15:44:06.011 -07:00 [INF] Updating existing https binding :443 (flags: 0)
2020-04-03 15:44:06.027 -07:00 [INF] Committing 1 https binding changes to IIS
2020-04-03 15:44:06.261 -07:00 [INF] Uninstalling certificate from the certificate store
2020-04-03 15:44:06.261 -07:00 [DBG] Opened certificate store My
2020-04-03 15:44:06.261 -07:00 [INF] Removing certificate [Manual] builder.domainremoved.com @ 2020/4/3 13:41:44 from store My
2020-04-03 15:44:06.276 -07:00 [DBG] Closing certificate store
2020-04-03 15:44:06.276 -07:00 [INF] Next renewal scheduled at 2020/5/28 15:44:05
2020-04-03 15:44:06.292 -07:00 [INF] Renewal for [Manual] builder.domainremoved.com succeeded

Reloading the website and checking the SSL cert in the binding showed the new expiration date of the cert which was the valid time now. So it took rolling back to 2.1.4.710 (Release from 02/04/2020) as I read in the Release Notes that there were changes to the way renewals worked in 2.1.6.1 so that is why I went with 2.1.4.710 for the replacement version attempt, although looking back I think I could have gone with 2.1.5.742 and that should have resolved it as well. The real domains and Thumbprint ID's have been changed to suite a public comment like this.

I have not tried this on the other 4-5 machines I have win-acme installed on, luckily I only updated one other install to 2.1.6.1 today when I saw that it was released so I will revert that additional machine's version back to 2.1.5.742 as that was what it has been running successfully since 03/12/2020 and I know the latest scheduled forced renewal attempt worked on that other machine with that version.

Please update this thread when the issue is resolved, which I take it will require some work to then produce a new version of win-acme.

_Originally posted by @jon-f-novastor in https://github.com/win-acme/win-acme/issues/1484#issuecomment-608769766_

[jon-f-novastor]

@WouterTinus the link in my comment where I found a similar issue and resolution (of downgrading the version to older) should be https://github.com/win-acme/win-acme/issues/942 and not https://github.com/win-acme/win-acme/issues/692. If you could edit the above comment / report with the 942 link. Also where I said "I was able to resolve this issue by overwriting the 2.1.6.1 files with 2.4.1.710 files", that is incorrect, please replace that with 2.1.4.710.

As a follow-up to my issue post here is some additional info regarding the parameters used where I noticed the issue with win-acme 2.1.6.1 (note all of this was installed and discovered today in a few hour period along with replacing the 2.1.6.1 core files with 2.1.4.710 to fix it): I performed a clean install of win-acme 2.1.6.1 today on a system that never had it prior, and used the wacs.exe GUI to create Manual cert entry. The system is Server 2008 R2 (so it is not officially supported) using IIS 7.5 with a single HTTPS/443 site binding which already existed in place (with a paid SSL cert tied to it). I wanted to replace that binding with new cert. The GUI went all the way through and created the cert successful and it shown in the binding without me doing anything after that (I did not have to manually bind the cert in IIS Manager). My renewal attempts for the scheduled task where I told it to force the renewal, since I wanted to test the email notification and have the email for the renewal come through never was sent so I went and checked the logs and sure enough the force renewal did not replace the existing LE SSL cert in the single binding in IIS Manager, to replace the existing with the new, nor was that new cert showing in the list of available certs in IIS Manager. The log details that I mentioned in the comment are what I saw after that forced renewal ran, where it showed that the Thumbprint ID was the same as prior so it did not bother binding the new SSL cert (or possibly storing it in Windows Certificate Store even), as the Thumbprint ID's were all the same.

Downgrading the version from 2.1.6.1 to 2.1.4 fixed this as I mentioned, just overwrote the existing 2.1.6.1 core program files and did not re-do the configuration or re-create any SSL certs, with no other actions needed. I just ran the force renewal by adding the --force command to the existing Scheduled Task and ran it once more. Now the newest Thumbprint ID was newer than the past attempts, and the new cert mapped to the IIS binding to overwrite the existing few hour old LE cert from earlier today that was in place originally with 2.1.6.1 clean install (which worked fine the first run but broke in the subsequent --force renewal attempts).

I was only using the built in Windows Task Scheduler scheduled task that the program created for me to run the renewal when it was running 2.1.6.1 earlier today (before downgrading the version), but I did add the --force command into the task's action statement as I did not want to wait 60 days to try it again. At the time the reason why I wanted to run the renewal again today was to see the email notification come through for the successful cert renewal which does not appear possible unless the cert is either due for renewal or it is forced to be renewed (but that is another question). It seems as though even if you have Email Notification all setup and perfect in the settings file, after the installation is completed, and the email tests execute fine from wacs.exe, that running wacs.exe at that point and creating the first SSL certificate does NOT appear to send an email to state that the certificate was installed / created the first time it creates the cert. It only occurs for renewals to send the email notification, even though your email notification / server stuff is set in place properly it waits until the first renewal which could be 60 to 90 days after installing the application and issuing / deploying the first cert. This is why I like to force the renewal to occur, so that I can tell that everyone will get the email, and I don't want to wait 60 days to do so. I know that the email test function should in theory work after installing the application however.

Your app is great, I really enjoy it. I'am coming from ACMESharp for ACMEv1 which uses powershell scripts as you are most likely aware of, and so I was in need of replacing that with an ACMEv2 client, the WACS GUI is so nice comparatively! I could have stuck with the replacement for ACMESharp but it had many changes to the scripts to make so I looked for an alternative to doing that and discovered win-acme. Thank you

[jon-f-novastor]

@WouterTinus let me know if you need me to test the fix in a particular build. Thank you.

[jon-f-novastor]

@WouterTinus I have tested this and it is working. Thank you!