Cerrar
InicioCertificadosPon un Certificado Wildcard (Comodín) en tu Infraestructura IT

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):

Certificado Wildcard para todo.jpg

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:

NOTA: Lync Server no admite certificados de comodín, salvo cuando se usan para resumir las direcciones URL simples a través de proxy inverso. Se deben definir nombres alternativos del firmante (SAN) por cada nombre de dominio SIP, Servicio perimetral de conferencia web, Servicio perimetral A/V y dominio XMPP que la implementación ofrezca.
Habiendo leido este artículo, tenemos claro que no se soportan certificados wildcard para Lync/SkypefB, pero si fuese así nos ahorraríamos unos €/$ importantes en cuanto a certificados. En todos los artículos sobre certificados para Lync/SkypefB siempre he recomendado el tener dos certificados:
  • 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:

Certificados_EDGE_Parte_II_2.png
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

Certificados_EDGE_Parte_II_3.png

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:

Certificados_EDGE_Parte_II_4.png
Certificados_EDGE_Parte_II_5.png

Certificados_EDGE_Parte_II_6.png

Y si reviso el fichero de log después de ejecutar el cmdlet Get-CsWindowsService -verbose… mirad como se ha iniciado todo sin problemas:Certificados_EDGE_Parte_II_7.png

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:

“Nunca dejéis de “complicaros la vida” por no querer darle algunas vueltas a la cabecita, porque con POCO SE HACE MUCHO!!!”
Actualización del C
Bloquear la instalac

sbuytrago@asirsl.com

NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This