Make Certbot on Windows stay up-to-date

[bmw]

This issue is solved by https://github.com/certbot/certbot/pull/7539. This issue is blocked on https://github.com/certbot/certbot/issues/8046.

[bmw]

I think we should do this soonish and I may move this back to this milestone, but the milestone is currently pretty stuffed and I don't think we MUST do this this month so I'm kicking this to the next milestone for now.

[bmw]

I wanted to share some early thoughts on a potential proposal for how to verify updates to Certbot on Windows. The approach currently in https://github.com/certbot/certbot/pull/7539 is to pin the key in our Windows code signing certificate, however, I don't really want to go that route anymore, especially after some of our trouble with certbot-auto.

Instead, what if we securely generated 3 different keys. I would have one, Erica would have one, and the other would be a backup. We would then obtain two code signing certificates. We'd have one for my key and one for Erica's key. We could obtain a 3rd code signing cert for the backup key if needed.

Our update mechanism is satisfied as long as the key in the code signing cert is any of those keys. If we need to modify the list of trusted keys in the future, we can do so by modifying the code and shipping an update signed with one of the previously trusted keys.

I like this approach because we can do things like directly generate the private keys directly on smart cards and not worry about backups of individual keys. The only downside I see with this approach other than having to pay for multiple code signing certs is if someone installs Certbot on Windows, it is for some reason prevented from checking for updates for a long time, we rotate keys, and then the install starts checking for updates, the update may not be trusted. This is not a big enough problem to dissuade me from leaning towards this approach though.

What do other people think?

[adferrand]

Well, my initial thought on that matter was to have two public keys stored in the update mechanism, with one of them mapped to an actual signing certificate while the other was a backup just in case. So I completely agree with that approach if we can afford two signing certificates.

[webprofusion-chrisc]

Hi, in case it's useful here is the powershell script we optionally make available to Certify The Web users: https://github.com/webprofusion/certify/blob/development/src/Certify.Shared.Extensions/Scripts/AutoUpdate/AutoUpdate.ps1

This only verifies the download based on the expected hash (pulled from our update check api). The installer itself is signed, but that's not verified here (for in-app updates, which are done using .net, we compare the organisation).

Note that you can indeed do updates from within the process itself (e.g. certbot), you just have to launch your replacement installer then immediately quit your process. The CTW installer (using InnoSetup) has a quiet mode designed to just install and this is also useful (and required) for installing via Chocolatey or winget.

Incidentally I came to see if you had an open issue of the installer not being signed, so +1 to #8046 - I'd advise just using one code signing key on windows and don't take a dependency on a particular version of it.

[ohemorange]

#8046 is merged, so I'm removing the blocked tag, but we might want to give it another release to make sure everything is running smoothly before merging the PR.

[github-actions[bot]]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[github-actions[bot]]

This issue has been closed due to lack of activity, but if you think it should be reopened, please open a new issue with a link to this one and we'll take a look.