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.
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.
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]
Does the certificate provided have any impact on the run time behavior (i.e. does the run time handling ever check to see if the certificate is Verisign vs. Komodo for example)?
Would this impact the 'silent' installation process by sometimes requiring user intervention?
I'm trying to get a handle on why this is a problem for my client.
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.)
