Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ensure that update only to the application signed with same cert #1187

Closed
cumajkeee opened this issue Jan 30, 2017 · 28 comments · May be fixed by qcif/data-curator#563
Closed

ensure that update only to the application signed with same cert #1187

cumajkeee opened this issue Jan 30, 2017 · 28 comments · May be fixed by qcif/data-curator#563

Comments

@cumajkeee
Copy link

@cumajkeee cumajkeee commented Jan 30, 2017

I want to be sure that Windows (NSIS) application can update only to the application signed with same cert.

For Squirrel.Mac it works. When I try to update Mac application, that is not signed/signed with different cert to the correct application (signed with correct cert) I get error during update.

Same thing seems not working for Windows one.

@develar, could you please suggest something?
Thanks in advance.

@develar
Copy link
Member

@develar develar commented Jan 30, 2017

It is planned functionality. And must-have functionality since Windows security model just *** and cannot protect users.

https://technet.microsoft.com/en-us/library/ee176840.aspx will be used to verify that update is signed and signed exactly by you.

@develar develar changed the title [Question] How I can ensure I'm updating to the signed applicaiton ensure that update only to the application signed with same cert Jan 30, 2017
@cumajkeee
Copy link
Author

@cumajkeee cumajkeee commented Jan 30, 2017

Perfect, thanks! Is it up in backlog, or planned for someday? :)

@develar
Copy link
Member

@develar develar commented Jan 30, 2017

planned for someday

... when all critical issues like #1106 or #1172 will be fixed.

Issue is not closed backlog, so, it is planned to be fixed in short term (but as it is an open source project, it can took years :) without PR or donation).

@JanEgner
Copy link

@JanEgner JanEgner commented Feb 10, 2017

Just wondering if there's going to be an easy way to cover the case of an expiring code signing certificate, i.e. when the update must be signed using a different certificate than the one used for the installed version, but both certs are issued to the same person/org.

@develar
Copy link
Member

@develar develar commented Feb 10, 2017

@JanEgner Expired Code Signed Cert is always valid regardless is it expired or not. Because electron-builder always sign it using timestamp server. http://stackoverflow.com/a/4417480/1910191

@JanEgner
Copy link

@JanEgner JanEgner commented Feb 10, 2017

@develar Yes, but some day my cert will expire and I will have to get a new one. Stuff that I signed in the past, using the now-expired cert, will continue to be considered signed. But for my next update I need to use the new cert - i.e. a different one than for the installed version.
This would be an issue if you plan to check that the cert fingerprint is the same for the update as for the installed app.

@develar
Copy link
Member

@develar develar commented Feb 10, 2017

@JanEgner Yes. Nice question. Will be checked not by cert SHA256/SHA1, but by "Issued to" field. So, during build electron-builder will remember certificate publisher and on update exe signature will be verified:

  1. must be signed and valid.
  2. publisher still the same.
@JanEgner
Copy link

@JanEgner JanEgner commented Feb 10, 2017

Yes, that sounds great!
(unless the publishing company changes its name - which my employer did several times in the past years - so it would be extra-cool to be able to set an alternative accepted publisher name during build).

develar added a commit to develar/electron-builder that referenced this issue Feb 10, 2017
develar added a commit to develar/electron-builder that referenced this issue Feb 11, 2017
develar added a commit to develar/electron-builder that referenced this issue Feb 12, 2017
@cumajkeee
Copy link
Author

@cumajkeee cumajkeee commented May 3, 2017

Hey @develar, there is some extra work planned for this issue?

MariaDima added a commit to MariaDima/electron-builder that referenced this issue Jun 5, 2017
develar added a commit to develar/electron-builder that referenced this issue Jun 6, 2017
…gned with same cert

Close electron-userland#1187
develar added a commit to develar/electron-builder that referenced this issue Jun 6, 2017
…gned with same cert

Close electron-userland#1187
develar added a commit to develar/electron-builder that referenced this issue Jun 6, 2017
…gned with same cert

Close electron-userland#1187
develar added a commit to develar/electron-builder that referenced this issue Jun 6, 2017
…gned with same cert

Close electron-userland#1187
@develar develar closed this in 66771d3 Jun 6, 2017
@develar
Copy link
Member

@develar develar commented Jun 6, 2017

Please use win.forceCodeSigningVerification to disable this check. Check is not performed if app is not signed.

@JanEgner
Copy link

@JanEgner JanEgner commented Jun 6, 2017

Awesome - thanks a lot @MariaDima and @develar!

@cumajkeee
Copy link
Author

@cumajkeee cumajkeee commented Jun 8, 2017

@develar, @MariaDima I still can update signed application to not signed.

@develar
Copy link
Member

@develar develar commented Jun 8, 2017

@cumajkeee Please specify version of electron-updater. Is "signed application" was build by latest electron-builder (specify version).

@cumajkeee
Copy link
Author

@cumajkeee cumajkeee commented Jun 8, 2017

"electron-updater": "2.1.1",
"electron-builder": "18.6.2"

@cumajkeee
Copy link
Author

@cumajkeee cumajkeee commented Jun 8, 2017

Any updates so far?

@develar
Copy link
Member

@develar develar commented Jun 8, 2017

@cumajkeee As soon as my working day will be over, I will take a look ;)

@MariaDima
Copy link
Contributor

@MariaDima MariaDima commented Jun 9, 2017

I checked, but with latest electron-updater 2.1.2.
I get errors for the cases where the update has not been signed at all or has been signed using a "different" certificate.

@develar
Copy link
Member

@develar develar commented Jun 9, 2017

@MariaDima Thans for verification.
@cumajkeee Please ensure that there is publisherName in your app-update.yml file (this field automatically added by electron-builder).

@MariaDima
Copy link
Contributor

@MariaDima MariaDima commented Jun 9, 2017

One more note:
In case someone uses the setFeedURL method, you need to make sure you update the options with the proper "publisherName".

@KochiyaOcean
Copy link

@KochiyaOcean KochiyaOcean commented Jun 13, 2017

Is update of an unsigned application still allowed?

@develar
Copy link
Member

@develar develar commented Jun 13, 2017

@KochiyaOcean Must be not in the latest electron-updater.

@KochiyaOcean
Copy link

@KochiyaOcean KochiyaOcean commented Jun 13, 2017

@develar OK I think I would stuck on electron-updater@1 until found an affordable cert.

@develar
Copy link
Member

@develar develar commented Jun 14, 2017

@KochiyaOcean If your app is unsigned at all, update of an unsigned application is allowed. You are not forced to use code signing on Windows.

@KochiyaOcean
Copy link

@KochiyaOcean KochiyaOcean commented Jun 14, 2017

@develar Understood. Thanks 👍

@vhmth
Copy link

@vhmth vhmth commented Aug 3, 2019

@develar we've updated our org (and cert) from Opentest, Inc. -> Loom, Inc. Since the publisher name is now different, how should I go about this update? Just tested our staging app and it seems we run into an error telling us the update isn't signed by Opentest, Inc.

Is the only way forward:

  1. Ship a new build with Opentest, Inc. cert that disables the check via win.forceCodeSigningVerification=false
  2. Force people to upgrade to that version
  3. Ship a new update with the app signed by Loom, Inc. and add that check back in

?

@paulius005
Copy link

@paulius005 paulius005 commented Aug 3, 2019

exact error for what @vhmth mentioned here:

Error: New version 0.22.18 is not signed by the application owner: publisherNames: Opentest, Inc., raw info: {
  "SignerCertificate": {
    "FriendlyName": "",
    "IssuerName": {
      "Name": "CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US",
      "Oid": "System.Security.Cryptography.Oid"
    },
    "NotAfter": "/Date(1597838400000)/",
    "NotBefore": "/Date(1564704000000)/",
    "PrivateKey": null,
    "PublicKey": {
      "Key": "System.Security.Cryptography.RSACryptoServiceProvider",
      "Oid": "System.Security.Cryptography.Oid",
      "EncodedKeyValue": "System.Security.Cryptography.AsnEncodedData",
      "EncodedParameters": "System.Security.Cryptography.AsnEncodedData"
    },
    "SerialNumber": "03387E856C29FB71D1EA8C720C1A703F",
    "SignatureAlgorithm": {
      "Value": "1.2.840.113549.1.1.11",
      "FriendlyName": "sha256RSA"
    },
    "Thumbprint": "4C2D6BB4572616B6544AD006A6DA220CC9B95A49",
    "Version": 3,
    "Issuer": "CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US",
    "Subject": "CN=\"Loom, Inc.\", O=\"Loom, Inc.\", L=San Francisco, S=ca, C=US"
  },
  "TimeStamperCertificate": {
    "Archived": false,
    "Extensions": [
      "System.Security.Cryptography.X509Certificates.X509KeyUsageExtension",
      "System.Security.Cryptography.X509Certificates.X509BasicConstraintsExtension",
      "System.Security.Cryptography.X509Certificates.X509EnhancedKeyUsageExtension",
      "System.Security.Cryptography.X509Certificates.X509Extension",
      "System.Security.Cryptography.X509Certificates.X509Extension",
      "System.Security.Cryptography.X509Certificates.X509SubjectKeyIdentifierExtension",
      "System.Security.Cryptography.X509Certificates.X509Extension",
      "System.Security.Cryptography.X509Certificates.X509Extension"
    ],
    "FriendlyName": "",
    "IssuerName": {
      "Name": "CN=DigiCert Assured ID CA-1, OU=www.digicert.com, O=DigiCert Inc, C=US",
      "Oid": "System.Security.Cryptography.Oid"
    },
    "NotAfter": "/Date(1729555200000)/",
    "NotBefore": "/Date(1413936000000)/",
    "HasPrivateKey": false,
    "PrivateKey": null,
    "PublicKey": {
      "Key": "System.Security.Cryptography.RSACryptoServiceProvider",
      "Oid": "System.Security.Cryptography.Oid",
      "EncodedKeyValue": "System.Security.Cryptography.AsnEncodedData",
      "EncodedParameters": "System.Security.Cryptography.AsnEncodedData"
    },
    "SerialNumber": "03019A023AFF58B16BD6D5EAE617F066",
    "SubjectName": {
      "Name": "CN=DigiCert Timestamp Responder, O=DigiCert, C=US",
      "Oid": "System.Security.Cryptography.Oid"
    },
    "SignatureAlgorithm": {
      "Value": "1.2.840.113549.1.1.5",
      "FriendlyName": "sha1RSA"
    },
    "Thumbprint": "614D271D9102E30169822487FDE5DE00A352B01D",
    "Version": 3,
    "Handle": 1863111192016,
    "Issuer": "CN=DigiCert Assured ID CA-1, OU=www.digicert.com, O=DigiCert Inc, C=US",
    "Subject": "CN=DigiCert Timestamp Responder, O=DigiCert, C=US"
  },
  "Status": 0,
  "StatusMessage": "Signature verified."
}
@billoneil
Copy link

@billoneil billoneil commented Mar 9, 2020

@vhmth @paulius005 Do you remember how you got past this issue?

@vhmth
Copy link

@vhmth vhmth commented Mar 10, 2020

@billoneil we ended up shipping an update with the old (still current at the time) cert that would point to a new build that opened up the allowed publisher names to both Opentest (old) and Loom (new) and pointed to a new bucket for updates. We then had all builds signed with the new cert in that new bucket. This allowed us to get everyone onto the latest Opentest build (which is valid based on the time of cert, not the time of day that the app is run).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

8 participants