[DRAFT] ci: Monitor Windows signing certificate expiry #36673

willcl-ark commented at 10:14 AM on October 27, 2026: member

Currently we have no automation in place to check that our code signing certificates are not expired or close to expiry. We have previously "relied on Release Candidates" as a dry-run for codesigners to realise that a certificate has expired and have time to fix it. "Noticing during RC cycle" also might not be appropriate in the future if we release more bugfix minor/patch releases on short notice.

In place of this process we can run a weekly CI job which will check the certificate's validity and open an issue when it passes an expiry threshold.

In this draft we only check the windows cert (as I couldn't find a mac one) and we set the alert threshold to 90 days.

When the threshold is passed, the job will open an issue in this repo (optionally tagging relevant key-holders).

DrahtBot commented at 10:14 AM on October 27, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

External sites

Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36673
Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36673.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36673#author-ralph

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

willcl-ark commented at 10:16 AM on October 27, 2026: member

I've tested a run in my fork here with an increased threshold of 365 days to trigger posting an issue which was correctly opened here.

fanquake added the label Windows on Oct 27, 2026

hebasto commented at 10:43 AM on October 27, 2026: member

... we set the alert threshold to 30 days.

What's the rationale for this length period?

willcl-ark commented at 10:45 AM on October 27, 2026: member

... we set the alert threshold to 30 days.

What's the rationale for this length period?

There is no current rationale for this, it's a placeholder for now. It depends I guess on the average lead-time to obtain updated keys.

achow101 commented at 1:20 PM on October 27, 2026: member

It depends I guess on the average lead-time to obtain updated keys.

The lead time has been anywhere between a couple days, to about 2.5 months, depending on whether a change of CA and signing org was necessary.

willcl-ark force-pushed on Oct 27, 2026

willcl-ark commented at 3:57 PM on October 27, 2026: member

The lead time has been anywhere between a couple days, to about 2.5 months, depending on whether a change of CA and signing org was necessary.

Bumped the placeholder example threshold to 90 days.

in .github/workflows/code-signing-certificate.yml:38 in 1760a02463

  33 | +          GH_REPO: bitcoin/bitcoin
  34 | +        shell: bash
  35 | +        run: |
  36 | +          CERT=contrib/windeploy/win-codesign.cert
  37 | +          WARNING_DAYS=90
  38 | +          # The first certificate in the PEM bundle is the code signing certificate.

hebasto commented at 6:53 PM on October 29, 2026:

Is anything enforcing that order?

willcl-ark commented at 6:59 PM on October 29, 2026:

There is not (nice question).

The only way I know to "check" which is which, without hardcoding, is to check CA:FALSE to at least rule out that its a cert authority.

I can push a change to this perhaps.

willcl-ark commented at 8:57 PM on October 29, 2026:

Amended slightly in b7e371b634a

hebasto commented at 7:06 PM on October 29, 2026: member

Alternatively, we could amend the release process as suggested in #36695 (comment).

willcl-ark commented at 7:08 PM on October 29, 2026: member

Alternatively, we could amend the release process as suggested in #36695 (comment).

Yep! No skin off my back either way; happy with either approach.

ci: Monitor Windows signing certificate expiry

Check the signing certificate on master weekly so maintainers have time
to renew it before Windows release signing is affected. Open an issue
within 90 days of expiry, including certificate details and the checked
commit.

b7e371b634

willcl-ark force-pushed on Oct 29, 2026

fanquake commented at 8:56 PM on October 29, 2026: member

Alternatively, we could amend the release process as suggested in

Can you explain what that solves? The certs are constantly used to produce (point) releases, not just major releases, so always need to work (particularly in the case of expedited releases, like this week).

A note in an issue telling someone to manually look at the cert at an arbitrary future time is not useful if we want to know the cert works for a deployment tomorrow.

maflcko commented at 9:15 PM on October 29, 2026: member

I think the idea was to include a new section, which is either:

2027-01-04 Update Windows signing cert 🚧

Expires 2027-MM-DD

or:

2027-01-04 Update Windows signing cert :heavy_check_mark:

Expires 2029-MM-DD, not needed

Maybe a script can be added for this to make it easier to run, if needed. Trusting the CI to create such an issue (which I presume happens less than once a year) seems more brittle? But no strong opinion.

DrahtBot added the label CI failed on Oct 29, 2026

DrahtBot removed the label CI failed on Oct 30, 2026

fanquake commented at 10:36 AM on October 30, 2026: member

I think the idea was to include a new section, which is either:

Ok. I think the point of this PR is to try and move away from manual tasks that (hopefully) someone will remember to do, and more towards (automated) assurance that we can use the certs (my understanding is that the cert could also be revoked arbitrarily, along with normal expiration). Having this assurance would mean one less thing that an rc cycle needs to "check". Adding a note seems fine, but that seems to assume the cert is always valid?

I think we should also add a similar check for macOS code-signing, given that is more prone to breakage (needs manual intervention multiple time a year to accept updated T&Cs). An automated check makes more sense in this case, because the breakage is somewhat arbitrary.

willcl-ark commented at 10:37 AM on October 30, 2026: member

I think we should also add a similar check for macOS code-signing

To my knowledge the cert is not checked into this repo? but otherwise can trivially add the second check.

maflcko commented at 11:55 AM on October 30, 2026: member

I am just a bit unsure if some random bash encoded in a string inside a yaml inside a mutable GHA VM inside some MS datacenter that requires a GHA write token to create an issue over the API is more reliable than the status quo. Again, no strong opinion, but the script should probably be stand-alone, so that it can be run locally?