Estos días he estado intentando instalar Office 2007 en un Windows XP recién instalado. El caso es que, inexplicablemente, y aunque ejecuté el instalador como administrador, una y otra vez recibía el mensaje siguiente:

"Windows installer service cannot update one or more protected windows files."

No podía entenderlo. Jamás me había pasado. El caso es que sorprendentemente y aunque había instalado todo Windows XP prácticamente la solución consiste en añadir manualmente un archivo que no tiene el sistema. Para encontrar la solución en Internet, tela...

1. Desde el disco de instalación de Windows en su carpeta i386 busca el archivo FP40EXT.CAB y ábrela.

2. Buscaa dentro el archivito: fp4ault.dll.

3. Extráelo a la carpeta C:\Archivos de programa\Archivos comunes\microsoft shared\web server extensions\40\bin

Ahora intenta instalar de nuevo Office 2007 y verás como te funciona. Vivir para ver :-(

Lo cierto es que no sé para qué rayos quiere la instalación una DLL de Frontpage, pero espero que a alguien le ahorre mucha frustación.

Es que este tío, Javier Aguilera, es muy bueno :-)

La verdad es que esto lo sé desde hace ya tiempo pero hasta ahora no me he decidido a hacerlo público.

Tengo la suerte y el honor de ser ponente en el próximo TechEd Developers, el evento internacional para desarrolladores más importante dentro del mundo Microsoft. Y encima tengo la suerte de compartir ponencia con mi buen amigo Iván González, un crack:

Pulsa para aumentar

Nuestra ponencia se titula "ASP.NET Instrumentation and Health Monitoring" y os dejo el "abstract" de la misma para que sepáis de que va:

"It´s not everything about program functionality and functional requirements. What about post-deployment health and monitoring?. Keep your programs productive and virtually bug-free.

Develop ASP.NET applications aware of the event log, performance counters and trace listeners, keep applications under control and get ready before problems strike.

Dive into the IIS7 expanded monitoring & diagnostics capability through features like Runtime Status & Control data, Failed Request, etc...

We will see how to implement health measures in both application code (ASP.NET 3.5) and hosting (IIS 7.0) in order to ensure continuity."

Está en inglés porque la ponencia será en inglés, claro (es un evento internacional). Tendremos la suerte de compartir "cartel" con gente tan conocida como David Chappell, Steve Lasker, Michael Howard o Daniel Moth, por citar unos pocos.

La verdad es que tanto Iván como yo estamos muy contentos porque creo que se pueden contar con los dedos de la mano los españoles que han tenido la oportunidad de ser ponentes en TechEd. Además este año estamos que nos salimos los españoles, porque aparte de Iván y yo también será ponente Miguel Jiménez y nuestro ponente más internacional y autor del libro de Windows Communication Foundation de Krasis Press, Hadi Hariri.

¡Deseadnos suerte!

Y por supuesto, si estás por Barcelona la semana del 10 de noviembre a ver si te vemos por allí :-)

En mi anterior post os hablaba sobre la forma de poder utilizar varios certificados SSL en un mismo servidor y las posibilidades y limitaciones técnicas que existían.

Un certificado de servidor para SSL suele ser un producto caro. El precio en una entidad certificadora decente van desde unos pocos cientos a más de 1.000 euros, dependiente del tipo de certificado. Además es un proceso tedioso ya que hay que demostrar fehacientemente que somos quiénes decimos ser (que es de lo que va todo esto realmente, claro), lo que implica envío de papeles para su verficación, llamadas, faxes, etc... Conviene seleccionar una entidad certificadora conocida ya que de este modo su certificado raíz, que la verifica a ella primeramente, estará ya instalada en nuestro equipo, cosa que no ocurre con otras menos comunes (y supone una barrera comercial importante para éstas últimas). Todo el sistema de infraestructura de clave pública (PKI) se sustenta en esas relaciones de confianza jerarquizadas.

El objetivo de un certificado digital de servidor (para SSL) es triple ya que pretende lo siguiente:

1.- Autenticación del servidor: sirve para constatar ante los usuarios, de forma fiable, que el servidor al que se están conectando es quién dice ser y que por lo tanto nos estamos conectando de verdad a nuestro banco o servicio on-line.

2.- Cifrado de comunicaciones: la clave pública del servidor se utiliza para cifrar las comunicaciones iniciales, en las que se acuerdan el método de cifrado simétrico y la clave de cifrado que se utilizarán para cifrar todas las comunicaciones posteriores. Eso asegura la confidencialidad de las comunicaciones entre cliente y servidor, y es uno de los motivos por los que no se pueden simultanear certificados como hemos visto en el post anterior, ya que hasta la URL que se solicita viaja cifrada.

3.- No repudio de las comunicaciones realizadas por parte del servidor.

Cuando estamos desarrollando una aplicación y la queremos probar con SSL, o bien cuando sólo queremos el certificado SSL para un uso restringido (por ejemplo para nuestros dos o tres usuarios móviles que se quieren conectar cuando están fuera de la oficina), quizá el coste de un certificado real no está justificado. Para generar un certificado propio podemos poner en marcha nuestra propia infraestructura PKI, para lo cual Windows Server viene preparad. Aunque nos resultará fácil montar una PKI propia puede que no esté justificado todo el trabajo que conlleva para genrar uno o dos certificados.

Para permitir a los desarrolladores el uso de certificados SSL sin tener que comprarlos o generarlos con una PKI propia, en el interesante Kit de Recursos de Windows Server 2003 que ya hemos mencionado en el anterior post, se incluye una pequeña utilidad de línea de comandos que te va a encantar. Se trata de SelfSSL.exe.

Este ejecutable nos permite generar para cualquier servidor virtual de IIS un certificado digital SSL que está firmado por nosotros mismos. Lo genera y además lo instala y deja listo para su uso. La utilización de SelfSSL es muy sencilla:

Así, para generar un certificado SSL para un servidor virtual que tenga una validez de un año y que valide al dominio zonasegura.midominio.com tendría que escribir algo como esto:

selfssl /T /N:CN=zonasegura.midominio.com /V:365 /S:1669802537

El valor para el parámetro /S es el identificador d enuestro servidor virtual y, como hemos visto, lo sacamos con la utilidad IIS Metabase Explorer. Además he añadido el parámetro /T para que el certificado generado se instale en la lista de certificados de confianza del navegador local. De este modo en el servidor de pruebas no recibiremos advertencias sobre que el origen del certificado no se puede validar.

Y es que este es el mayor inconveniente de estos certificados: al acceder mediante SSL a los sitios protegidos con ellos recibiremos una advertencia de seguridad delnavegador, ya que el certificado no está emitido por una entidad de confianza reconocida. Esto es lógico sino el uso de certificados "de verdad" carecería de sentido, pues se perdería su objetivo principal que es la confianza, y pervertiríamos el concepto subyacente a las PKI.

No obstante, incluso en estas condiciones y aparte de su uso para pruebas y desarrollo, este tipo de certificados auto-firmados pueden ser muy útiles, ya que nos permiten conseguir el objetivo 2, es decir, el cifrado de las comunicaciones. Si por ejemplo tenemos algún trabajador que esporádicamente está de viaje y se quiere conectar al webmail o a una aplicación desde una red pública (un WiFi en una cafetería o centro comercial, por ejemplo) podemos utilizar uno de estos certificados para cifrar las comunicaciones y que las claves no viajen en claro y puedan ser interceptadas. No nos valida el servidor pero tampoco tenemos esto si nos conetcamos de forma "normal", por HTTP, y sería muy raro que alguien intentara suplantar justo a nuestro webmail usando envenanimiento de DNS en un centro comercial para engañar a un comercial nuestro y robarle las credenciales ¿no? ;-)

Es decir, ni se te ocurra usar esto para una aplicación de verdad ni para algo a lo que deban acceder muchos usuarios, pero para pruebas y para conexiones esporádicas a sistemas no críticos nos permitirá ahorrarnos un dinero y conseguir al menos el cifrado de datos en las conexiones, lo que no es poco.

Espero que te sirva :-)

El título es así de largo proque realmente trato varios temas que están relacionados yq ue a muchos programadores Web les pueden a resultar útiles.

Primeramente, pregunta típica: ¿puedo utilizar varios certificados SSL (Secure Sockets Layer) en un mismo servidor Internet Information Server (IIS)?

Respuesta: Sí y No.

Un servidor IIS 6.0 permite por defecto asignar varios certificados a servidores virtuales diferentes siempre y cuando éstos funcionen cada uno en un puerto distinto. Así, si usamos en alguno un puerto no estándar (distinto al 443), pues entonces sí nos deja, pero vamos, esto dista bastante de ser una buena solución. También nospermite tener dos certificados en dos servidores virtuales diferentes si cada uno de ellos utiliza una IP distinta. Tampoco es muy útil.

Si vamos al diálogo "Avanzadas" de la pestaña general de propiedades de un sitio Web de IIS, veremos que aunque en peticiones sin encriptar nos permite definir tantos encabezados de host como queramos en la misma IP y mismo puerto para así distinguir unas peticiones de otras, en el caso de SSL sólo nos deja indicar una IP y un puerto, sin posibilidad de distinguir encabezados de host:

Por este motivo, si en dos sitios Web utilizan la misma IP y el puerto estándar 443 y les asociamos un certificado de servidor para que cifren las ocmunicaciones con SSL, en cuanto lo hagamos con el segundo éste se nos parará. No nos dejará arrancarlo de nuevo porque nos dice que no puede haber dos servidores escuchando en el mismo puerto.

Si tuviésemos la posibilidad de distinguir las peticiones SSL por encabezado de host, como pasa en peticiones normales sin encriptar, entonces ya estaría el tema solucionado. El problema es que, por definición, la información viaja encriptada (incluyendo la petición y el encabezado de host) por lo que IIS no tiene manera de determinar ese encabezado de host hasta que lo desencripta en el servidor con el certificado adecuado. Es decir, que si antes no sabe qué certificado utilizar entonces no puede determinar el encabezado de host que tiene la petición, y viceversa. Es un típico problema recursivo que crea esta limitación. Antes de que algún anti-MS salte a la yugular diré, por si no está suficientemente claro aún con la explicación, que se trata de una limitación de SSL no de IIS. Le pasa a todos los servidores web.

Entonces ¿cómo solucionamos el asunto?

Bueno, la conclusión es que sólo podremos distinguir entre unas peticiones y otras si usamos para todas ellas el mismo certificado. Pero por definición cada sitio web (con un dominio distinto) tiene que tener un certificado diferente, o entonces podríamos desencriptar pero fallaría la autenticaicón del servidor pues no se correspondería con el dominio (¿me explico?). Por lo tanto la única solución es que todos esos dominios que queremos proteger deben tener el mismo dominio o subdominio principal, y debemos asignar al servidor un certificado comodín, es decir, uno que sirva para proteger un dominio y todos sus subdominios.

Así, podremos proteger con un mismo certificado comodín por ejemplo a los dominios: shop.campusmvp.com, www.campusmvp.com y aulas.campusmvp.com, o cualesquiera otros que compartan un mismo sufijo en el dominio. El certificado que usemos debe certificar al dominio comodín: *.campusmvp.com.

Estos certificados comodín los tenemos que pedir expresamente a nuestro proveedor de certificados (Thawte, verisign, Camaras.org o quien sea). Generalmente son bastante más caros que los normales puesto que, realmente, les estás fastidiando el negocio porque con un solo certificado proteges varios dominios, así que se aseguran unas ganacias penalizándote el precio.

Si tienes que proteger varios dominios distintos no te quedará más remedio que asignarle una IP diferente a cada uno. Efectos secundarios de la seguridad ;-)

Asignación de encabezados de host a cada subdominio

Vale. supongamos entonces que quieresproteger varios subdominios con un certificado comodín. Según he dicho antes no vamos a poder de todos modos establecer el encabezado de host porque la herramienta de administración de IIS no nos lo permite. Entonces ¿cómo lo hacemos?

El proceso es el siguiente. Instalas el certificado en el primero de los dominios y le asignas el puerto 443 a la IP que le corresponda. Ahora debes usar una herramienta de script administrativo de IIS para establecer el encabezado. Abres una línea de comandos, vas hasta la carpeta de scipts administrativos (por defecto C:\InetPub\AdminScripts) y escribes lo siguiente:

cscript.exe adsutil.vbs set /w3svc/<ID del servidor virtual>/SecureBindings ":443:subdominio.dominio.com"

Por ejemplo:

cscript.exe adsutil.vbs set /w3svc/1669802537/SecureBindings ":443:mcs.krasis.es"

Vale. Primera dificultad: hay que averiguar cuál es el identificador de nuestro servidor virtual :-?

Para ello tienes que irte a la metabase de IIS y buscarlo entre todo ese infernal XML :-( Así que mucho mejor vamos a usar una herramienta que lo haga por nosotros. Si te descargas el Resource Kit de IIS 6.0, dentro del mismo hay una herramienta llamada IIS Metabase Explorer que te permite hacer lo que su nombre indica: bucear en la metabase sin tener que lidiar directamente con ella. Instálala y podrás averiguar fácilmente el identificador de tu servidor virtual viéndolo en el nodo correspondiente de la rama LM\W3SVC, como en esta figura:

Pulsa para aumentar

Con esto es coser y cantar pues sólo tienes que copiar el "numerito" y ya podrás asignarle el certificado al subdominio (o subdominios) que necesites.

Ahora sólo resta repetir la misma operación en el resto de subdominios/servidores virtuales y listo.

Espero que esto le resulte útil a mucha gente.

En el próximo post voy a comentar algo muy interesante relacionado con este tema: cómo crear y asignar automáticamente certificados SSL a nuestros dominios creados y firmados por nosotros mismos para pruebas o para uso privado. Y lo mejor: sin tener que instalar ningún tipo de infraestructura PKI (Infraestructura de clave pública) y con un simple programita de línea de comandos :-)