This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Code signing generates internet query?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2013
02:27 PM
Code signing generates internet query?
Hi,
I have a customer that is reporting that my installation is doing an internet query related to the code signing certificate associated with my product. Does anyone know anything about this? It makes some sense to verify a certificate by checking on the internet... but my customer needs to be able to install on machines that are not connected to the internet. Are there code signing certificates that do not require a query to the internet (the one we have is from Comodo)? I'm really not very knowledgeable about this topic - any information will be appreciated.
Thank you,
Andy Canham
I have a customer that is reporting that my installation is doing an internet query related to the code signing certificate associated with my product. Does anyone know anything about this? It makes some sense to verify a certificate by checking on the internet... but my customer needs to be able to install on machines that are not connected to the internet. Are there code signing certificates that do not require a query to the internet (the one we have is from Comodo)? I'm really not very knowledgeable about this topic - any information will be appreciated.
Thank you,
Andy Canham
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 22, 2013
10:43 AM
This sort of behavior is controlled by whatever is verifying the certificate. Typically the signing itself will require internet access to acquire a "timestamp" counter-signature that helps extend the life of the signature. Then at run time, a client may choose to verify whether the certificate used to sign the exe or msi has been revoked. It will do so in part by checking the certificate revocation lists. Most unconnected clients would either skip this step, or proceed with their old information if the Internet is not accessible.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 22, 2013
11:14 AM
MichaelU wrote:
This sort of behavior is controlled by whatever is verifying the certificate. Typically the signing itself will require internet access to acquire a "timestamp" counter-signature that helps extend the life of the signature. Then at run time, a client may choose to verify whether the certificate used to sign the exe or msi has been revoked. It will do so in part by checking the certificate revocation lists. Most unconnected clients would either skip this step, or proceed with their old information if the Internet is not accessible.
Thank you - that helps. A couple of follow-up questions if you don't mind:
[LIST=1]
I'm trying to get a handle on why this is a problem for my client.
Regards,
Andy Canham
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 24, 2013
09:36 AM
The vendor of a certificate only really influences its chain of trust, and the exact address for the revocation list that could include it. The chain of trust issue primarily shows up in unconnected machines that haven't recently updated their "root" certificates. The symptom is they do not trust certain validly signed files. Typically if that machine then gets its certificates updated, it will begin to trust such a file.
Almost all cases I'm aware of with certificate verification begin before the installation is launched; once you're within the installation, it has been implicitly or explicitly approved, and if it does any further certificate checks it does them against data stored in the installer (for example the compressed .cab files of a .msi install can be signed, and the certificate information for such a signature is stored in the msi databse). The exception I can think of is with our Suite/Advanced UI projects with an update URL: if the new package is not signed with the same certificate as the base package, it must prompt the user, and will refuse to launch the updated package in silent installations. (If the signing certificate is a match it will work fine silently.)
Almost all cases I'm aware of with certificate verification begin before the installation is launched; once you're within the installation, it has been implicitly or explicitly approved, and if it does any further certificate checks it does them against data stored in the installer (for example the compressed .cab files of a .msi install can be signed, and the certificate information for such a signature is stored in the msi databse). The exception I can think of is with our Suite/Advanced UI projects with an update URL: if the new package is not signed with the same certificate as the base package, it must prompt the user, and will refuse to launch the updated package in silent installations. (If the signing certificate is a match it will work fine silently.)
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)