Cerrar
InicioCertificadosCertificados, Certificados y más Certificados para Lync y Skype For Business

Certificados, Certificados y más Certificados para Lync y Skype For Business

He publicado varios artículos sobre los certificados que necesitamos para nuestra implementación de Lync o Skype For Business … (pulsar en la imagen para verla a tamaño real):

Certificados Lync-Skype_Final.jpg

Voy a tratar de enforcar de forma más directa las necesidades de certificados para Lync / Skype For Business y que tipo de certificados podemos implementar. En un artículo anterior (¿Qué certificados necesitamos para Lync?), había hecho un resumen de los requisitos en cuanto a certificados a implementar en Lync. Ahora lo único que quiero es “volver” a comentar que tipo de certificados necesitamos y de que entidades de certificación podemos solicitar los certificados y sean válidos para nuestra implementación.

Vamos a empezar por aclarar los PROS y CONTRAS sobre la utilización de certificados emitidos por una Entidad de Certificación Privada o Pública, voy a tratar de resumirlo (y mucho) en el siguiente cuadro:

Certificados Lync-Skype_Final_1.jpg

Veamos por cada tipo de Entidad Certificadora los datos del cuadro anterior:
Entidad Certificadora Privada: PROS
  1. Ahorro Económico: claramente, porque el coste de los certifidados seria de 0€, puesto que implementariamos una Entidad de Certificación Privada en uno de los servidores que tengamos en el dominio ( a ser posible no en ningún servidor de Lync ni Controlador de Dominio). Los certificados son 100% válidos para nuestra implementación
  2. Flexibilidad: desde luego que sí, podemos porque podemos emitir los certifidados que queramos y cuando queramos, cambiarlos en cualquier momento y todo a coste 0. Si cambiamos o añadimos dominios SIP en nuestra Topología de Lync/Skype4B lo haríamos sin problema alguno
  3. Federaciones: Se pueden utilizar sin problema alguno, pero siempre y cuando enviemos nuestro certificado raíz a la empresa con la que nos queremos federar para que lo instale en su EDGE. Esto es para que vea el EDGE con el que nos queremos federar como válido los certificados que le presenta nuestro propio EDGE.
Entidad Certificadora Pública: PROS
  1. Certificado válido en el 99,99%: si implementamos un certificado público en los servicios que publicamos hacia internet (EDGE, Servicios Web de los Front-END) de los servicios de Lync/Skype4B, los equipos (Linux, Windows, MAC, etc..) ya tienen los certificados raíz e intermedios de las Entidades Públicas más extendidas (DigiCert, VeriSign, GeoTrust, etc..). Por lo que si configuramos un certificado público de algunas de estas compañías (y otras muchas), siempre veremos el certificado cómo válido puesto que nuestro equipo ya tiene estos certificados raíz e intermedios indicados. Aquí puntualizo que si utilizamos el certificado emitido por nosotros e instalamos el certificado raíz en el contenedor de certificados local  del equipos también lo veremos como válido, pero claro, nosotros no lo podemos publicar en el resto de equipos del mundo como bien comprenderéis. Lo que quiero decir, que el funcionamiento del certificado privado es igual que el público, pero con un certificado de una CA privada tenemos que instalar el certificado de forma manual para que se vea como válido. Dicho esto, los certificados raíz de las entidades de certificación Públicos los podemos ver  desde el almacén de certificados del equipo local (desde una consola de certificados del equipo). Certificados Lync-Skype_1.jpg
  2. Federaciones: es válido para federarse con cualquier implementación de Lync/Skype4B y también con los servicios de IM Públicos (Skype (versión de consumo), Skype Online, Google, etc.), por la misma razón que en el punto 1, porque se utiliza un certificado público que´el resto de servicios de los proveedores lo ven como válido. ¿Se podría utilizar con certificados privados? SI, pero .. sería inviable enviarle a Microsoft  nuestro certificado raiz para lo instale en sus servidores, no solo por el elevado número de peticiones de empresas para enviarles su certificado raíz, sino por todos los problemas de seguridad que esto podría presentar, vamos, INVIABLE (pero no técnicamente).  Además, lo suyo es que el certificado sea público y así sea validado directamente por los servicios del proveedor y se vea como válido (y otras miles de razones, pero por simplificar)
Entidad Certificadora Privada: CONTRA
  1. Federaciones con sistemas de IM Públicas: Esto es lo comentado en el punto nº2 de los PROS de los certificados públicos, como los proveedores no tienen instalado nuestro certificado raíz, no verán a nuestro servidor como de confianza puesto que verán errores de intercambio de certificados porque no es de confianza para el.
  2. Instalación del certificado raíz: Esto no es que sea un problema, pero si es bastante engorroso hacerlo si tenemos cientos de equipos a los que tenemos que instalar el certificado raíz y están fuera del dominio. Todos los equipos que están en el dominio ya no tienen problema, se les instala de forma automática el certificado raíz. Por ejemplo, si tenemos dispositivos móviles y queremos que se conecten a Lync/Skype4B y están dentro de la red (resolución DNS interna) tendrán que instalarse el certificado raíz en el dispositivo. Tenemos varias “soluciones” para esto:
    1. Formar a los usuarios para que tengan conocimiento de como instalar el certificado raíz en su dispositivo
    2. Configurar un segundo Reverse-Proxy desde dentro de la red y ahí tener un certificado público para que los usuarios se conecten a los servicios web vía Reverse-Proxy (hay que modificar los registros DNS si los dispositivos siguen utilizando los DNS internos). Esto es una “solución” alternativa a no tener que instalar el certificado raíz en cientos dispositivos móviles. Los registros que debemos modificar serían el lyncdiscoverinternal y el FQDN del servicio web externo que hayamos configurado en la topología, la IP que debe tener es la IP “externa” del Reverse-Proxy, y claramente ahí tengamos un certificado público (sino no servirá de nada). Pero antes de hacer este cambio, revisar este artículo: ¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?.
    3. Disponer de una herramienta de gestión de dispositivos móviles que permita de forma remota instalar el certificado
  3. Mantenimiento de la CA: Esto no tengo claro que se pueda ver como un CONTRA, pero bueno siempre  tendremos que mantenerlo y actualizar las CRL u OCSP (esto no, pero bueno tiene que estar activo). Siempre tenemos que estar atentos a la renovación de la clave del certificado raíz, publicar las CRL, etc… siempre es algo a tener en cuenta y que si lo instalamos en local debemos tener cuidado con ello. Ver este vídeo que había publicado en su momento y fijaros en la parte de la configuración de las extensiones, es MUY IMPORTANTE y que los administradores no lo suelen tener en cuenta: Windows Server 2012, Instalación de una CA

 

 Entidad Certificadora Pública: CONTRA
  1. Ahorro de Costes: claramente no, los certificados públicos tienen un coste y en ocasiones importante
  2. Flexibilidad: Esto va ligado al ahorro de costes, podemos hacer lo que queramos con el certifidado (tener uno simple, uno SAN, uno Wildcard, uno Wilcard y SAN a la vez, etc..) pero siempre que hagamos algún cambio … toca pasar por caja. Esto con una Entidad Privada de Certificación no ocurre, cambiamos la veces que queramos, solicitamos los certificamos que necesitemos, revocamos los actuales cuando deseemos, etc..
Analizados los PROS y CONTRAS de los tipos de Entidades de Certificación, la pregunta es: ¿Qué tipo de certificados y entidad certificadora necesito/puedo implementar para nuestra topología de Lync/Skype4B? Yo lo tengo claro, una mezcla de ambos, certificados PRIVADOS para los servicios internos y PÚBLICOS para los servicios externos:
Certificados Lync-Skype_2.jpg
De esta forma para los usuarios que se conectan desde dentro de la red o más bien corporativos, como ya tienen el certificado raíz en sus equipos  se podrán conectar a todos los servicios sin problema. Y para los usuarios que se conecten desde fuera de la red lo harán vía EDGE y Reverse-Proxy, que será en donde tengamos los certificados públicos (con todo lo que ello conlleva). Así tenemos lo mejor de los dos escenarios, flexibibilidad y una gestión de costes equilibrada.
Ahora podría surgir otra duda: ¿Certificados SAN o Wildcard para los servicios públicos? Pues aquí, yo lo tengo claro, certificados SAN para el EDGE y WildCard para el Reverse-Proxy y os explico el porque (darle una vuelta a este artículo que había publicado en su momento: Certificados SAN o Wildcard para nuestra implementación de Lync Server):
  • SAN: Porque es el escenario más común cuando tenemos varias direcciones IP Públicas disponibles para los servicios de Lync/Skype4B, se tienen varios FQDN asociados a los distintos servicios y necesitamos un certificado que tenga los nombres que tenemos configurados.
  • WildCard: NO es obligatorio que sea wilcard y también podemos tener uno SAN, pero si tenéis varios servicios a publicar con los FQDN como subdominio (mail.dominio.com, office, dominio, lyncweb.dominio.com, etc…) lo suyo es tener uno wildcard porque con un certificado con el sujeto *.dominio.com podemos publicar todos los subdominios que se quieran y no tenemos que un certificado SAN (límite de 100 nombres (no todos, pero tomarlo como dato)) con varios nombres. Además, si tenemos varios dominios SIP podemos tener un certifidado WildCard con varios dominios (*.dominio.com, *.dominio2.com, etc..), lo que faciilta que con mismo Reverse-Proxy, una sola IP Pública podamos publicar los mismos servicios pero con subdominios diferentes.
 En estos dos escenarios este artículo puede seros de mucha utilidad: Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública. Por último también tenemos que nombrar a los certificados SIMPLES, certificados con un solo nombre. Estos son viables para el EDGE, habría que configurar el mismo nombre para todos los servicios y misma dirección IP:
SRV-LYNC00-2014-03-25-07-39-40-1.png
Aquí el “problema” es que los servicios no tendrán el puerto estandard (443/TCP), tenéis que cambiarlo y esto es posible que os pueda causar algún problema cuando estáis en un red fuera de la corporativa y tengan algún tipo de filtrado de puertos de salida, pero de lo contrario es un escenario 100% válido.
Dicho todo esto y por resumir, aquí os dejo mis conclusiones sobre los certificados y entidades certificadoras a utilizar:
  • Utilizar certificados de vuestra CA privada en todos los servicios internos (EDGE (Interno), Front-END, Mediation Server, Chat Persistente, Director, Office Web App, Exchange (EWS))
  • Utilizar certificados de entidades de certificación públicas en los servicios externos de la topología (EDGE, Reverse-Proxy)
  • Certificado SAN (públicos) para el EDGE y WildCard para el Reverse-Proxy

Y ahora que debemos tener en cuenta cuando solicitemos un certificado para nuestra topología:

  • El nombre que tenga el certificado debe coincidir con el nombre del servicio configurado en la topología. Si es un certficado SAN, pues tendrá todos los nombres que sean necesarios.
  • Los certificados asociados a los Front-END, se solicitan desde el asistente y ya se encarga el de solicitar los nombres que necesita (igualmente, antes de completar la solicitud revisarlos). Revisar  estdos dos vídeos, que os ayudarán a entender como se solicitan e instalan los certficados en los Front-END y EDGE: Asignar Certificados a un Front-END de Lync Server 2013, Asignar Certificados a un EDGE de Lync Server 2013

De sobra es sabido, que para que se vean como certificados válidos para un sistema, se deben cumplir los siguientes requisitos:

  • El nombre del certificado debe corresponderse con los servicios publicados
  • Debe estar en fecha (no caducado)
  • Los equipos que se conecten a los servicios de Lync/Skype4B deben tener el certificado raíz instalado en su almacén local de certificados (si el certificado es privado y están fuera del dominio debe instalarse de forma manual)
  • Si utilizáis dispositivos móviles pensar cual es vuestro mejor escenario, eso ya depende de cada  cliente (número de dispositivos móviles, administración, etc..).
Por último, aquí os dejo algunos artículos anteriores sobre certificados y que creo que os pueden servir de ayuda:

Cada día los certificados están más presentes en cualquier tecnología, para los que no os habéis metido de lleno a conocer el funcionamiento de los certificados, deberíais empezar cuanto antes. Como véis en Lync/Skype4B es vital conocer bien que es un certificado y como implementarlo, sino no funcionará absolutamente nada. Mirad este esquema de tráfico entre los servidores de Lync/Skype4B (es un poco antiguo, pero para que tengáis una referencia nos sirve):

Certificados Lync-Skype_3.jpg

Como todo en la vida, si se tiene conocimiento todo es más sencillo y veréis como la tecnología funciona y funciona muy bien, sino terminaréis desquiciados porque no os funcionará nada o crereéis que todos son problemas. La evolución de Lync a Skype (Migración paso a paso de Lync Server 2013 Standard a Skype For Business 2015 Standard, Migración paso a paso de Lync Server 2013 Enterprise a Skype For Business 2015 Enterprise) no ha cambiado nada con respecto a los certificados, se solicitan y se necesitan de la misma forma.

No sé si os he aclarado algo más el tema de los certificados o lo he complicado más, pero espero que sea lo primero!!!o sé si os he aclarado algo más el tema de los certificados o lo he complicado más, pero espero que sea lo primero!!!

Skype for Business S
Sitio Oficial de Sky

sbuytrago@asirsl.com

1 COMENTARIO
  • Juan Rodriguez / 10 diciembre, 2019

    Excelente aporte, realmente cuando has trabajado meramente administrando, mas no implementando hay detalles que se escapan y no es fácil clarificar cierta información, por tanto, gracias por su tiempo, muy bien explicado.

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