7

I have an electron app that originally was distributed with a certificate for an individual developer.

I'd like to now sign the next update to that app with a certificate from my organization, but when I do so, existing installations (upon auto update) throw an error that the code requirements aren't met.

Is there a way to properly sign an electron app with both the old and new certificate? I'd like to prevent my existing users from being interrupted.

Any help appreciated!

Thanks

jamis0n
  • 3,610
  • 8
  • 34
  • 50

1 Answers1

10

We had a similar situation, with an Electron application for MacOS using auto-update, and we needed to switch to a new certificate without making everyone download and re-install the application manually. The auto-update process needs to recognize the new certificate. Rightfully so, the old version will refuse to update if the new certificate is not recognized.

Our strategy was:

  • look at the designated requirement (or DR) of the application, when signed with the old certificate, using codesign -d -v -r - <path-to-app>
  • look at the designated requirement of the application when signed with the new certificate
  • place the combined designated requirement, that includes both certificates, into an electron-builder-requirements.txt file
  • make sure that you do not include the identifier in the combined designated requirement string
  • make a reference to the electron-builder-requirements.txt in the electron-builder.yaml file (add a line under mac: like this requirements: electron-builder-requirements.txt)
  • publish a new version of the app, signed with the old certificate, but with the DR that contains information about both certificates
  • wait until nearly everyone has the version running on their desktop that includes mention of both certificates in the DR
  • update the build so that it uses the new certificate instead, and remove the electron-builder-requirements.txt file
  • release a new version of the app signed with the new certificate (no requirements file is needed, and it will list only its own cert in the DR)

An older version of the application that has a DR that includes information about both certificates will allow an auto-update to a new version that uses either certificate.

I found this document about signing code manually helpful in understanding the "designated requirement".

Update: here's an example of the electron-builder-requirements.txt file (I've modified some of the letters/numbers for privacy purposes):

designated => certificate leaf = H"2323ce6b0XXXXXXXX39f2064be999999997272b1" or anchor apple generic and certificate 1[field.1.2.840.199995.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.199995.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "6ZXXXXXXUY"
Van Boughner
  • 324
  • 2
  • 8
  • 1
    thanks so much for your answer! do you perhaps have an example of your electron-builder-requirements.txt file? I am having a bit of hard time getting the exact syntax or combined reqs right. – Misha Reyzlin Dec 04 '19 at 14:21
  • 1
    @MishaReyzlin I have edited the answer to include an example of the electron-builder-requirements.txt file. Good luck, and I hope you are able to get it working! – Van Boughner Dec 06 '19 at 01:06
  • 1
    can you explain how you did this : place the combined designated requirement, that includes both certificates, into an electron-builder-requirements.txt file is there a way to get a combined designated requirement? – Elmo Aug 16 '20 at 22:07
  • 1
    Creating the combined designated requirement is a step that needs to be done manually. I looked at the designated requirement for the application when signed with the old cert and also when signed with the new cert. I combined the two by using "or". See the electron-builder-requirements.txt file that I included above. Everything after "designated =>" is the combined designated requirement. Look for the "or" there, which divides the two designated requirements from each other. – Van Boughner Aug 17 '20 at 23:28