Pon un Certificado Wildcard (Comodín) en tu Infraestructura IT
Volvemos la carga con el tema de los certificados, puesto que he querido hacer una prueba que me gustaría comentar con todos vosotros. La idea es poner un certificado wildcard/comodin en un EDGE … puesto que para el resto de servicios web que publicamos vía Reverse-Proxy está 100% soportado y funcionando (pulsar en la imagen para verla a tamaño real):
En este artículo voy a tratar de exponer mi experiencia con la instalación de un certificado Wildcard (comodín) en un EDGE, algo que “aparentemente” no está soportado por Microsoft:
- SAN: para el EDGE
- WILDCARD: para el Reverse-Proxy y desde ahí publicar todos los servicios que tengamos y no sólo Lync/SkypefB (Exchange, SharePoint, Blogs, Webs, etc..)
Pero dicho esto y por no repetirme (leer este artículo: ¿Qué certificados necesitamos para Lync?), os comento que he probado la instalación de un certificado Wildcard sobre un EDGE y sin obtener nada “interesante” en particular, si me gustaría comentar la corta experiencia que he tenido.
Primero veamos que ocurre cuando instalamos un certificado wildcard en un EDGE, pero básicamente el único problema es este:
Como podéis apreciar, la advertencia es que el certificado no contienen en el sujeto el nombre del servicio de acceso (en mi caso sip.asirsl.com) y luego que como alternativos al sujeto tampoco aparecen los de webconf.asirsl.com, sip.asirsl.com, etc… vamos, que le faltan nombres al certificado para el EDGE aún a pesar de ser un wildcard, el cual para otros servicios funciona perfectamente. Se supone que si esto fuera crítico, los servicios no se iniciarían (sino probad con un certificado que no sea wildcard y no tengan los nombres que habéis configurado en la topología), pero cuando he revisado los servicios se habían iniciado correctamente y sin advertencia alguna: Get-CsWindowsService
Esto a nivel de PowerShell, los servicios están iniciados, pero luego quería ver el Visor de Sucesos y verificar si todo se ha iniciado sin problemas y juzgarlo vosotros mismos:
Y si reviso el fichero de log después de ejecutar el cmdlet Get-CsWindowsService -verbose… mirad como se ha iniciado todo sin problemas:
Con todos los servicios iniciados la duda sería si funcionaría todo y estas son las pruebas realizadas:
- Inicio de sesión fuera de la red corporativa, vamos como un usuario externo: Rápido y sin advertencia alguna sobre el certificado
- Sesión de AV con usuarios de dentro de la organización: Sin problema
- Compartir escritorio, pantallas, etc..: Sin problema
- Llamadas de VoIP: Sin problema
- Sesiones de AV, IM, etc.. con usuarios federados de otras instalaciones On-Premises: Sin problema
- Sesiones de AV, IM, etc.. con usuarios federados de Skype For Business Online: Sin problema
- Sesiones con usuarios de Skype: Sin problema
Vamos, que ha funcionado todo perfectamente. Está claro que sino está soportado, no deberíamos realizar esta configuración, pero si bien es cierto reduciría el coste de implementación de Lync/Skype en cuanto al consumo de certificados a adquirir (que tampoco es la parte más notable del presupuesto con respecto al resto, pero bueno). Por lo que con un certificado wildcard podríamos publicar entiendo que el 100% de los servicios que tengamos en nuestra infraestructura IT:
- Lync/Skype
- Exchange
- SharePoint
- Blogs
- Web de APPS de negocio
- CRM
- Otros servicios web
Está claro que algunos servicios se publicarán mediante un Reverse-Proxy y el certificado se instalará en dicho reverse-proxy y para el EDGE pues se instalará en el EDGE. Comento esto, por si alguno viendo el esquema del artículo pueda llegar a confundirse, porque “parecen” estar unidos el EDGE y Reverse-Proxy por un mismo certificado, que sí lo es (el mismo certificado), pero claramente se instala de forma independiente en cada servicio.
Bueno, pues espero que os haya sido de intereés este artículo, aún no siento altamente técnico o instructivo, espero que por lo menos lo toméis en cuenta a la hora de adquirir certificados (para tener uno sólo wildcard o NO).
Aquí os dejo algunos artículos sobre Certificados y Reverse-Proxy que espero os ayuden a completar o entender el porqué de este artículo:
- Requisitos que necesita cumplir un Certificiado Digital para reconocerse como válido
- ¿Qué certificados necesitamos para Lync?
- Certificados SAN o Wildcard para nuestra implementación de Lync Server
- Emitir Certificados con más de 2 años de validez en una CA en Windows
- Lync Server: Modificar el tiempo de validez de un certificado de usuario
- Creación de CSR para Lync de forma sencilla
- Asignar Certificados a un Front-END de Lync Server 2013
- Renovar, Instalar y Asignar Certificados a nuestro Edge de Lync Server 2010/2013
- Lync Server: Un Edge, Un Certificado SAN para un Dominio, Múltiples Dominios SIP y Federaciones (Actualizado 12-06-2013)
- Lync Server: Un Edge, Un Certificado SAN para un Dominio, Múltiples Dominios SIP y Federaciones (Actualizado 12-06-2013)
- Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública
- Asignar Certificados a un EDGE de Lync Server 2013