Processing Ajax...

Title

Message

Confirm

Confirm

Confirm

Confirm

Are you sure you want to delete this item?

Confirm

Are you sure you want to delete this item?

Confirm

Are you sure?

User Image
Kristopher Walsh
14 discussion posts
My work now requires a "valid certificate" in order to install an application. As you can see in the attached images, the DF Cert is only valid until 7/26/2025.
I attached FreeCommander's cert as an example of what my company will allow me to install.
I would appreciate it if you would update the install file certificate and set the expiration a ways out. (:
• Attachment: Cert-FreeCommander-2023-2026.png [20,168 bytes]
Cert-FreeCommander-2023-2026.png
Cert-FreeCommander-2023-2026.png
• Attachment: DisplayFusion-Cert.png [20,748 bytes]
DisplayFusion-Cert.png
DisplayFusion-Cert.png
29 days ago  • #1
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
Hi Kristopher, thanks for letting us know about this. Code signing certificates are a bit different than a TLS certificate for signing web requests, for example. A TLS web signing certificate needs to be valid during the request for everything to be valid. With a code signing certificate all it's doing is telling you that this EXE/DLL is valid and is who it says it is because the certificate that signed it was valid when it was signed. Microsoft's own code signing service on Azure now uses certificates that are only valid for 3-7 days. I have attached a screenshot showing what the newly signed files look like. The shorter-lived certificates provide a greater level of security because they aren't sitting around with multi-year expiries waiting to sign things. If your work requires that an EXE be signed by a certificate that's still valid months or years after signing I think they're going to run into quite a few issues. I'm happy to answer anything other questions you might have as well, thanks!

image.png
• Attachment: image.png [53,485 bytes]
image.png
image.png
29 days ago  • #2
User Image
Kristopher Walsh
14 discussion posts
Thank you very much for the details!! Very useful ammo I can use to pimp 🤚 my IT dept! 😝
• Attachment: Pimp-Slap.gif [824,045 bytes]
Pimp-Slap.gif
Pimp-Slap.gif
21 days ago (modified 20 days ago)  • #3
User Image
JLJTGR
131 discussion posts
I personally find topics about the hidden workings of security to be interesting as I run across it in my daily job. It's even more interesting when everything is hidden in plain sight, but no one ever looks at it.

As some more ammo that you can use... here are some more details on how to manually verify signatures such as this. As mentioned before, EXE code signing, PDF signing and HTTPS signing all use the same methods and the time indicated is just as important as the validity period. When using HTTPS, your browser knows what time it is and will check that the certificate is valid for that time. If you change your system clock by a few years, you'll find that your browser no longer trusts anything.

PDF and EXE code signing similarly are valid at the time of signing. Just because time advances by years doesn't mean that the code signing is no longer valid. It was valid at the time. It only becomes invalid if the certificate is revoked by the issuer.

In web browsers, you know what time it is that instant... so you can trust the time easily. With PDF/code signing, you are told what time it was signed... but how can you be sure? The answer is a Time Stamping Authority. Similar to certifying an signer identity as with HTTPS/PDF/EXE signing... this service certifies a signer time for an object. They will give a cryptographic response for what they think the current time is.

In the Countersignatures section of DisplayFusion's Digital Signature Details, you can see Microsoft Public RSA Time Stamping Authority. This authority run by Microsoft is trusted by Windows and signifies that DisplayFusion was signed at a specific time. If that specific time is within the validity period of the identity certificate, then everything should be fine.

While this excercise is interesting to do once... even more when you start looking at thumbprints and object hashes... you shouldn't. Windows has already done all of this manual work for you. When it says "This digital signature is OK.", it already did these checks and a lot more. It would have complained if the certificate dates were bad. As Jon said, the validity range doesn't need to include today to use the program today. The program has not been altered since that signing date. It's cryptographically proven by the above.
• Attachment: 2025-10-08 16_30_20.png [92,423 bytes]
2025-10-08 16_30_20.png
2025-10-08 16_30_20.png
20 days ago  • #4
Subscribe to this discussion topic using RSS
Was this helpful?  Login to Vote(-)  Login to Vote(-)