1

A program A downloads signed executables and other signed configuration files. Configuration files have a signature appended at the end. To verify their integrity and creator, it uses the public key hardcoded in the program A.

In a couple of years, the certificate that was used to sign the files expires and a new one will be issued. Program A will download the newly updated files, but because it is using the old certificate's public key for validation, it thinks that the files were tampered with.

What is the "right" way for remotely installed programs to identify if an update is safe to apply? Hardcoding the public key is likely to be problematic.

Improve this question
12
  • Is it a certificate with a publicly accessible CA or is it “self signed”? Also, is there a certificate structure or just is there just a flat CERT with key (ea is there a branch & leaf certificate or not)
    – LvB
    Commented Aug 11, 2021 at 18:11
  • it's an DigiCert EV cert with publicly accessible CA. It has a certificate structure.
    – sanjihan
    Commented Aug 11, 2021 at 18:41
  • So you could consider pinning your certificate supplier as the only one that can supply a new certificate and verify the CERT used with ocsp.
    – LvB
    Commented Aug 11, 2021 at 18:53
  • 1
    Can’t you just send an update still signed with the old cert with a new cert to trust in it? Like 3/4 into the lifetime of the current cert you request a new one to start updating the app?
    – LvB
    Commented Aug 12, 2021 at 2:55
  • 1
    What if you sign the new certificate with the old certificate?
    – user20574
    Commented Mar 6, 2023 at 13:12

2 Answers 2

Reset to default
1

You didn't mention what technologies you are using or how the certificates are generated so it's hard to give an answer that is well-targeted for what you are doing, but I would suggest that you construct a chain of trust. You can make a certificate that contains the new public key, then sign it using the old key pair before that key pair expires, and ship the certificate with your executables. There are, of course, lots of details to figure out to make this be safe and secure.

When Windows announces that an executable has a verified publisher, it usually means that there is a chain of trust from a Trusted Root Certificate on the computer going to a publisher's certificate that was used to sign the software. The software can hold various certificates in it that the computer then uses to construct a chain of trust.

Improve this answer
0

I would not hardcode the public certificate, but rather use a config file, because updating it is much simpler. Anyway, you are left with 2 common ways:

  • if you can be sure of the exact moment of the certificate change, you will have to update your configuration (or you application if the certificate is hardcoded) at that exact time. Any failure in doing so, because either part has added a delay will result if rejecting legitimate files
  • or you can accept up to 2 certificates at the same time. In standart operation mode, you only use one. At renewal time you add the future certificate between the time it has been issued and the time it is used. And when you are sure the old one should no longer be used, you remove it.

That second way does require 2 changes per certificate renewal (first to add the new one and second to remove the old one) but it is much more tolerant to any delay...

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .