Expondré un escenario que nos ocurrió hace poco en una implementación de SharePoint:
Creamos una nueva SharePoint web application, de la forma que ya conocemos, esta web application llamada SecureWebApplication, usara ssl y vivirá en el puerto 80, por lo que la url que da de la siguiente forma: https://securewebaaplication. Al crear esta web application le asignamos un host header, ya que conocemos previamente de la existencia de otra aplicación que se está ejecutando en este puerto.
Después de que la creación de la web application y site collection se llevaron a cabo satisfactoriamente, nos percatamos que la web application no responde, vamos al IIS y encontramos con que el sitio está detenido, intentamos iniciarlo, pero aparece un mensaje indicándonos que existe otro sitio que se encuentra utilizando el mismo puerto.
Efectivamente, existen otros sitios que se encuentra en el puerto 80, pero con host-headers diferentes, entonces, ¿por qué no puede iniciar nuestro sitio web?
Un poco de aburrida teoría…
Existen tres datos que definen la unicidad de un sitio web, los cuales son:
Existen tres datos que definen la unicidad de un sitio web, los cuales son:
- Dirección IP
- Puerto
- Host name (host-header)
A la suma de estos tres datos se le conoce como binding, y define a un sitio web que escucha en una ip:puerto con un host-header especifico.
Cuando se recibe una petición, el componente HTTP.sys lee las propiedades de configuración del sitio al cual se hace la petición, tales como: tiempo de timeout, limite de conexiones y el certificado que utiliza el sitio
Cuando se recibe una petición, el componente HTTP.sys lee las propiedades de configuración del sitio al cual se hace la petición, tales como: tiempo de timeout, limite de conexiones y el certificado que utiliza el sitio
Pero para saber a qué sitio se está haciendo la petición, HTTP.sys utiliza el binding (los tres componentes arriba mencionados), recordemos que el certificado es necesario para desencriptar los datos encriptados que el cliente envía (en donde viene el host-header)
O sea, que tenemos una dependencia circular. Por una parte necesitamos el certificado para desencriptar la información enviada y de ahí recuperar el binding para a su vez poder leer las propiedades de configuración. Y por otro lado necesitamos primero leer las propiedades de configuración para obtener el certificado y así desencriptar la información que viene del cliente. WTF!
En IIS 7, cuando nosotros creamos un binding https en un sitio web, este automáticamente deshabilita el que nosotros podamos escribir el host-header, porque el host-header esta embebido en el certificado
Y después de toda esta reseña, la solución a esto es una pequeña utilería que se encuentra en la carpeta %windir%\system32\inetsrv, llamada appcmd, con la cual podemos forzar a que el host-header del https binding sea establecido. Con algo más o menos asi:
appcmd.exe set site /site.name:securewebaaplication /bindings.[protocol='https',bindingInformation='*:443:'].bindingInformation:*:443:securewebaaplication
Pueden revisar este enlace, para mas detalles.
1 comentarios:
hay che ciberto te la rifass....naaa
Publicar un comentario