Guide to upgrading code signing certificate + publisherName

[mixmix]

• Electron-Builder Version: 22.10.5
• Node Version: 14.6.0
• Electron Version: 12.2.2
• Target: Windows (for this issue)

This issue is a description of a problem my project had and a walkthrough of how I solved it. I'm writing this for future users so they don't have to piece together their own path like I did (because the documentation is unclear in places).
I'm also interested to hear if there are things I missed

Problem

The project I work on had a windows Code Signing Certificate which was for publisherName: "Ahau Limited NZ".
We decided to upgrade to an EV Signing Certificate (more expensive and restricted, but less scary warning for Windows users).

My boss bought ordered it for `"Āhau Limited NZ" (notice the macron on the Ā! This is the correct spelling in Maori, but I had avoided it because I had previously hit problems in config files with things not really liking non-english characters sigh)

You can change config.win.publisherName so it lines up with the new certificate but then auto-updater breaks (this is a good safety feature of electron-updater). The question then is how to handle a migration of name.

I've seen people struggling with this in:

• auto-update with new signing certificate #4664
• Windows 10 update isn't working due to new version is not signed by the application owner #3714
• ...

---

Possible solution paths

A. Rip it out!

Just change the certificate and publisherName.
This means the auto-updater will fail for old users (who will have to upgrade manually), but new users will be fine.

B. Migrate slowly

1. mint a new release with old certificate but change config to add new name

   win: {
     icon: 'build/win/icon.ico',
     publisherName: [
       'Āhau NZ Limited',  // new name
       'Ahau NZ Limited'   // old name
     ]
   }
   

2. wait a month for all users to upgrade?
3. mint a new version, swapping the signing certificates

NOTES:

• for (2) we have analytics installed (mixpanel) which report which versions users are running. This helps us know how many people might be left behind.
• for (3) I wasn't clear with the EV signing upgrades. What I wish I'd known:
  • for Code Signing Cert we used environment variables CSC_LINK, CSC_KEY_PASSWORD and a .pfx file, the EV signing we dropped those env var and allowed electron-updater the fine the EV Signing Cert I'd installed
  • I used config.win.certificateSha1 to specify the certificate. Documentation is currently lacking on this, see "Cannot find certificate" on Windows when EV signing #4626 (comment)

---

C. Combo

Upgrade immediately to the new certificate (like A), but have a pop-up for users who can't auto-update which tells them to go get the new version.

This one is tricky because you need to have some functionality already installed and published (e.g. something which checks an external server for changes and decides whether to alert the user. If you have a mailing list that could suffice too). If you don't you may need to install that functionality and wait for users to auto-update to install it.

I have a suspicion that you could mitigate this by :

1. create a major version jump which uses new certificate
2. create minor version jump which uses the old certificate but has an alert for users to manually upgrade

I think that electron-updater will only auto-update within semver minor/patch ranges, but haven't checked or run simulations/

[mixmix]

We're currently on path (B) but investigating (C).
I'll update this thread with how we go.

Would love to hear from others about if I missed anything, or if there are better ways

[tombertrand]

We've just tested the Option B with success. So we're planning on publishing a new release (using the old certificate) with the old and new publisherName. Hold until a good portion of the users are updated and push a new release with the new certificate publisher name.

We'll need a fallback solution (manual download link aka option C) if users were on previous versions and they get a certificate error but at that point it will only be a few.

Manual and auto-updates worked using that technique.

[Hexxeh]

I'm facing this issue too right now. One idea I had, was to switch the autoupdate files. Publish a new version under the old filenames that points to a new version, which points to new metadata files on the autoupdate server. This way, clients will have to update through the intermediary version.

It might require a little hand-editing of the files, but it seems the smoothest approach possible?

[mixmix]

That's a really interesting idea. Could work (though I've actually not opened those yml files to see what they contain!) One challenge is that all these solutions require careful testing. I've tried to document what I learnt through testing to save others time. Very interested to hear details if it works for you

…

On Fri, 7 Jan 2022, 09:18 Liam McLoughlin, ***@***.***> wrote: I'm facing this issue too right now. One idea I had, was to switch the autoupdate files. Publish a new version under the old filenames that points to a new version, which points to new metadata files on the autoupdate server. This way, clients will have to update through the intermediary version. It might require a little hand-editing of the files, but it seems the smoothest approach possible? — Reply to this email directly, view it on GitHub <#6499 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUK3HRG2THNSSILAYKEZ5LUUX2IPANCNFSM5KB5MJYQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Hexxeh]

Your documented info was very useful, thank you! I'll share what I end up doing here incase it's useful also.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mixmix]

bad bot. this issue is a resource and documentation collection point. leave it be

…

On Sun, 17 Apr 2022, 02:14 stale[bot], ***@***.***> wrote: Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. — Reply to this email directly, view it on GitHub <#6499 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUK3HXYWJE66ZC3UCY4WG3VFLDNJANCNFSM5KB5MJYQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jeetparikh]

hey @mixmix thank you for the awesome solution. Pretty much in the same pickle at the moment and found this solution via Hpop's help.

We would really like to use the solution B where we open the list of publishers. But for us, the org name has changed from A to B and the current version of the application is signed using a certificate issued to org A as publisher and is now expired. So we can no longer issue a certificate to org A (Digicert doesn't give EV cert to org A anymore as org A is now old name and they no longer consider it valid). And if we sign the app with new cert issued to org B the auto-updater fails.

Do you see any work around to this problem? We are really struggling with this and would not like to force users for a manual update. Your help is much appreciated. Thank you.

[mixmix]

@jeetparikh I'm not an expert... but, think of you let that certificate expire (if i understand) you are kinda screwed. you can no longer sign new versions which might have fixes.

best I can advise is you contact your users to get them to manual update, and then put in tools to avoid this problem in future.

one thing we have in our setup is analytics (via mixpanel) which reports what versions users are using. this helps us track how upgrades are going

[jeetparikh]

@mixmix thanks for getting back. Ya the certificate expiry feels screwed. I don't think that the expiry is more of a problem but rather the org name change. Otherwise we could get just get the renewal easily. Currently signing we newly renewed certificate but different subject/publisher breaks auto-update..
So no way for auto-update - like bypassing via publishers or getting a less strict version of the cert which is not EV certificate? Or any other ways you could think of? Just trying my options out here..

[mixmix]

@jeetparikh i know if no way to resolve your block. you should have planned ahead more.

please start a new thread to explore problem solving. this one is documentation recording solutions

[jeetparikh]

no worries.. thanks @mixmix .. appreciate your response and help.

[mixmix]

@jeetparikh hey sorry I am not technical support for you, and this is just a completely unrelated issue. Recommend you open another issue.
And if you want to reduce the noise in this thread where people are contributing to a specific issue about signing certs, then delete your unrelated comments.

I'm trying to be clear so GitHub issues are focused and helpful for everyone. I'm being blunt so you understand. I wish you well though. Good luck
🐠 🍍 ♥

[clemp6r]

What about macOS?

[mixmix]

This is about windows. Recommend starting a different issue for that if this thread didn't help you

[mfranzs]

Thank you for the suggestions here!

A tip for future people going through this process. You can avoid any timing issues here by switching the deploy bucket as a part of this build process:

1. Deploy a new version to your prior bucket where you only change the downloadURL to a new bucket you're hosting. In this change, add the publisherNames to the build.
2. In the new bucket, change the signing cert.

This ensures that all users first update to a version with the correct publisherName, then they update to the new signing cert.

To do this you can add a publisher option in your build config.

Etc we use this:

  publish: [
    /**
     * We use two publish configs here.
     * 1. The first 'generic' config provides the URL that the app actually fetches updates from. This is part
     *    of the electron-updater behavior - when multiple publish options are provided, the first is used to fetch updates.
     *    This config doesn't do anything in the build step.
     * 2. The second config is used only in the build step. 
     */
    {
      provider: 'generic',
      url: downloadURL,
    },
    {
      provider: 's3',
      bucket,
      endpoint: s3URL,
      acl: null,
    },
  ],