Este es uno de esos problemas raros que, si nadie te lo cuenta, es dificilísimo que llegues a solucionar por tu cuenta. Y si lo haces vas a estar días rompiéndote la cabeza antes de descubrir qué pasa...

Seguramente conocerás (o te sonará al menos) la tecnología Authenticode de Microsoft. Se trata de una forma de firma digital que nos permite verificar el origen de un código ejecutable (EXE o DLL), un documento o cualquier otro tipo de archivo.

El uso de una firma Authenticode permite verificar el desarrollador de una aplicación, de modo que puedas estar seguro de que aquel programa que te bajaste de Internet es una copia legítima generada por su creador, y no una versión modificada  que contenga algún troyano u otros virus. Es decir, no prueba que el ejecutable sea inofensivo, sino que prueba que al menos lo ha creado alguien concreto. ahora ya es cosa tuya si confías o no en ese determinado fabricante.

Así, al ejecutar un programa que te has descargado de Internet y que está firmado por un fabricante válido verás un diálogo similar a este:

Authenticode_Bien

 

Sin embargo cuando el ensamblado no está firmado (o no tiene un certificado válido), el aviso cambia e indica el peligro de ejecutarlo:

Authenticode_Mal

 

También puedes ver si un ensamblado está firmado o no usando sus propiedades desde el explorador de Windows, ya que ofrece una pestaña "Certificados" para ello. Este, por ejemplo, es el certificado de Excel.exe en mi equipo:

Authenticode_Cert
Pulsa para aumentar

Firmar un ensamblado es muy sencillo puesto que sólo necesitamos un certificado digital válido (que se puede adquirir on-line en multitud de sitios, normalmente en los mismos en los que compras certificados SSL), y usar la utilidad signcode.exe que viene con .NET:

signcode.exe -spc miCertificado.spc -v miClavePrivada.pvk miEnsamblado.exe

Es importante firmar los ensamblados en algunas ocasiones porque nos ayudan a poder usarlos en empresas en las que existen políticas de seguridad y sólo admiten ensamblados firmados. Adicionalmente, si los distribuimos por Internet, nos aseguramos de que no van a ser modificados sin nuestro consentimiento y le ofrecemos a los usuarios una forma de verificar que son auténticos.

¿Qué pasa con las aplicaciones Web?

Es más habitual de lo que creemos usar ensamblados firmados con Authenticode en aplicaciones Web. Por ejemplo, muchas bibliotecas de controles comerciales vienen firmadas de esta manera.

Obviamente, cuando se ejecutan en una aplicación Web no se muestran los diálogos de confirmación que hemos visto, ya que son aplicaciones sin interfaz, o mejor dicho, cuya interfaz se muestra en remoto, en el navegador. Entonces ¿qué se hace con ellos?

Pues hasta la llegada de .NET 4.0, en la que ha cambiado el sistema de seguridad por completo, lo que hace la CLR cuando carga un ensamblado firmado con Authenticode es tratar de verificar la firma. Este proceso implica conectarse a la red o a Internet (dependiendo de si el certificado usado es privado o de una entidad certificadora pública, que es lo más común), descargarse listas de revocación de certificados y también seguir la cadena de certificación hasta el certificado raíz.

En resumen: puede ser un procedimiento un poco lento que lleve incluso varios segundos.

En el caso de IIS  este proceso se realiza para cada nuevo hilo de ejecución, por lo que el efecto se multiplica.

Y lo que es peor: si no hay conexión a Internet, al cabo de unos cuantos segundos (15 o 20), se desestimará la comprobación del ensamblado pero habremos demorado su carga bastante tiempo. En las siguientes peticiones respondidas con este hilo ya se ejecutará bien, pues sólo se carga una vez por proceso.

El resultado es que en servidores que no tengan conexión a Internet y usen ensamblados firmados con Authenticode veremos demoras enormes a la hora de lanzar la aplicación. Una pesadilla de rendimiento difícil de solucionar si no sabemos este detalle. Aunque tengamos conexión a Internet el proceso normal de comprobación puede tardar un par de segundos, por lo que incluso en ese caso sería interesante desactivar esta comprobación si estamos seguros de la identidad del ensamblado.

Desactivar la comprobación de la firma

Existe un ajuste que podemos hacer en el archivo Machine.config (ubicado en C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG) que se denomina generatePublisherEvidence.

Éste permite desactivar la comprobación de las firmas evitando el proceso y por lo tanto eliminando la demora en la carga de los ensamblados.

Basta con escribir dentro de machine.config lo siguiente:

   1: <configuration>
   2:     <runtime>
   3:         <generatePublisherEvidence enabled="false"/>
   4:     </runtime>
   5: </configuration>

Con esto eliminaremos el problema.

IMPORTANTE: Reitero que esto sólo es aplicable para aplicaciones previas a .NET 4.0, es decir, hasta .NET 3.5 SP1. El motivo es que .NET 4.0, comoe s sabido, ha cambiado el modo de funcionamiento del sistema de seguridad CAS.

¡Espero que te sea útil!

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA