Pasos a seguir para hacer que un servicio web basado en WCF pueda consumirse vía HTTPS

Los siguientes son los pasos a seguir para hacer que un servicio web basado en WCF pueda consumirse vía https. Se parte de la base que el servicio web ya está instalado y que existe una aplicación web definida en IIS desde la cual se accede al mismo vía http. También se asume que el certificado digital se creará en el momento.

1- Ingresar al administrador de IIS 7.5, posicionarse en el nombre del servidor y luego hacer doble click sobre el icono de “Certificados de Servidor”.
2- En el panel de acciones, hacer click en el link de “Crear Certificado Autofirmado …”. En el formulario que se abre ingresar un nombre para el certificado y hacer click en “Aceptar”.
3- En la lista de certificados, tomar nota del valor de la columna “Emitido Para” del certificado recién creado. A efectos prácticos, vamos a suponer que dicho valor es “STI-PC-035.soluciones.com.ar”.
4- Posicionarse en el sitio web que contenga a la aplicación del web service, y en el panel de acciones, hacer click en el link de “Enlaces …”.
5- En el formulario que se abre, hacer click en “Agregar …”. En el nuevo formulario, seleccionar “https” en el combo de “Tipo”, y en el combo de “Certificado SSL”, seleccionar el certificado creado en el punto 3. En el resto de los campos dejar los valores por default. Finalmente, hacer click en “Aceptar” en ambos formularios para cerrarlos.
6- Posicionarse en la aplicación web en la cual se encuentra el servicio web y luego hacer doble click en el icono de “Configuración de SSL”.
7- Seleccionar la check box de “Requerir SSL”, y dejar la opción “Certificados de cliente” en “Omitir”. Finalmente, hacer click en “Aplicar” en el panel de acciones.
8- Abrir un intérprete de comandos (cmd) con permisos de administración y ejecutar los siguientes comandos:
a. cscript //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs get W3SVC/1/SecureBindings
i. Este comando debería devolver lo siguiente: “:443:”
b. cscript //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs set W3SVC/1/SecureBindings “:443:STI-PC-035.soluciones.com.ar”
i. El parámetro del comando debería coincidir con la columna “Emitido Para” del certificado.
ii. El comando debería devolver lo siguiente: “:443:STI-PC-035.soluciones.com.ar”
iii. Al hacer esto se estará modificando la url de acceso al web service en el wsdl, y al tener exactamente el mismo nombre que el certificado no se producirán errores de validación del mismo cuando se invoque al web service. Si no se hace este paso, entonces la aplicación cliente será responsable de modificar la url de acceso que está definida en el wsdl.
9- Editar el archivo web.config del servicio web, realizando los siguientes cambios:
a. Configurar el modo de seguridad del binding como “Transport”:
b. Asignar un valor al atributo “address” del endpoint (puede ser cualquier valor, pero “secure” es bastante descriptivo):
c. En el service behavior, agregar los atributos “httpsGetEnabled” y “httpsGetUrl” al nodo “serviceMetadata”, para que quede de la siguiente manera:

Nótese que el nombre del sitio web en la url debe coincidir con la columna “Emitido Para” del certificado, y que a la url se le agrega el sufijo “/secure”, que debe coincidir con el atributo address definido en el endpoint. Si no se hace esto, las herramientas que necesiten acceder al wsdl vía url van a tener errores de validación de certificado. Por otro lado, si se obtiene el wsdl en su versión de múltiples archivos (las definiciones de tipos están separadas en XSDs), también se producirán errores de validación de certificado.
d. En el service behavior, activar la página estándar del servicio web para https, agregando el atributo “httpsHelpPageEnabled” en el nodo “serviceDebug”, de la siguiente manera:

Este paso es opcional, sólo si se quiere acceder a la página estándar del servicio mediante la url base, que ahora será: https://sti-pc-035.soluciones.com.ar/WSEngage/WSEngage.svc.

Al ingresar a esa página, se podrán ver los nuevos links al wsdl de múltiples archivos o al de archivo único, que respectivamente son:
i. https://sti-pc-035.soluciones.com.ar/WSEngage/WSEngage.svc/secure?wsdl
ii. https://sti-pc-035.soluciones.com.ar/WSEngage/WSEngage.svc/secure?singleWsdl

Esto hay que tenerlo muy en cuenta, por si ya existen aplicaciones cliente apuntando al wsdl o a las urls anteriores.

Los pasos de 1 a 7 están documentados en el siguiente link: http://msdn.microsoft.com/en-us/library/hh556232(v=vs.110).aspx

El paso 8 está documentado en el siguiente link: http://blogs.msdn.com/b/wenlong/archive/2007/08/02/how-to-change-hostname-in-wsdl-of-an-iis-hosted-service.aspx