I was in a similar situation: an application signed with authentication on a server without the Internet access had an inexplicably significant delay in launching. Setting generatePublisherEvidence to false seemed to solve the problem, but I could not definitively explain why this was necessary.
The Microsoft documentation for the generatePublisherEvidence element confused me with these two notes:
In the .NET Framework 4 and later, this element does not affect assembly load time.
and
We recommend that services use this element to improve startup performance. Using this element can also help to avoid delays that can cause a timeout and cancellation of service startup.
After a lengthy investigation using Process Monitor , Certutil and Debugging . Source code of the .NET Framework , my conclusion:
The generatePublisherEvidence element is definitely still relevant for .NET 4, even 4.7, which I used! It is no longer the case that without it, the signature is always verified by the runtime as part of the assembly loading process, but the signature verification can still be called (inadvertently) at some point!
Read more.
.NET 2 and 3.5
The digital signature will always be verified when loading the assembly, as part of the initialization of the so-called evidence objects used by the code access mechanism (CAS). The publisher certificate, which was created from a digital signature, was not used by default in CAS, so most of the time it was a waste of time. And as explained here :
Authentication is confirmed by the addition of a start time. Authenticated assemblies are for inspection at a certification authority (CA). This verification may take a long time because it may require a network connection several times in order to download the current certificate of revocation lists. It also ensures that there is a complete chain of valid certificates for the path to a trusted root. This can lead to several seconds of delay in loading the assembly.
Consider installing a CA certificate on a client computer or avoid using Authenticode if possible. If you know that your application does not need proof of the publisher, you do not need to pay the cost of verifying the signature.
Starting with the .NET Framework 3.5, there is a configuration option that allows Authenticode verification to be bypassed. To do this, add the following parameter to the app.exe.config file:
<configuration> <runtime> <generatePublisherEvidence enabled="false"/> </runtime> </configuration>
.NET 4
Initialization of evidence objects has now been delayed to the actual level to avoid a launch penalty that leads to previous versions. This means that digital signatures are no longer always verified during the assembly loading process. But, it turns out, there are cases when all evidence objects are initialized, including rarely used publisher data!
In my case, I had an application that used the Oracle.ManagedDataAccess library to query the database at startup. This library relies on a specific configuration section ("oracle.manageddataaccess.client") in the application configuration. For some reason, I did not include such a configuration in my app.config file (and also in my machine.config).
When requesting this configuration section, the System.Configuration assembly, which is responsible for accessing the configurations, first view the machine.config file, and then in the application configuration. When it does not find the requested section in any of these, it searches for user configuration files located in the subfolder path% AppData%. The full path to these files includes a strong assembly name, so you must create compelling evidence.
The System.Configuration assembly then decides that all evidence objects should be initialized.
Since my application was digitally signed, this included initializing the publisher's evidence, which means verifying the signature, verifying the CRL and everything related to it. Publisher certification is not actually used, just proof of a strong name is part of the path to custom configuration files, so again this is just a waste of time.
Adding the "oracle.manageddataaccess.client" section to my app.config file avoids this, the full set of evidence objects did not need to be initialized, and the digital signature is no longer verified. Start delay did not pass.
In general, if you set the generatePublisherEvidence element to false, make sure that the proof publisher is not turned on whenever the structure decides that the evidence objects should be initialized!