Me sigo encontrando con muchas preguntas sobre los certificados, si cual debo comprar, que nombres debe tener, si sirve un certificado SAN o debe ser un certificado wildcard, etc… En una implementación de Lync Server podemos utilizar certificados privados, públicos o ambos. Yo siempre recomiendo ambos, lo que nos permitirá ahorrarnos un dinero importante. Veamos un escenario con certificados públicos y privados, los certificados privados los utilizaremos para la configuración de todos los servicios internos y que no tendrán acceso directo con usuarios externos:
- Front-END
- EDGE
- FQDN del servidor (certificado interno)
- FQDN del Pool (certificado interno)
- Director
-
WAC
Y para los servidores que si estarán expuestos a internet, debemos tener certificados públicos si queremos evitar enviar a los usuarios que se conectan a Lync el certificado raíz de nuestra CA y para federarnos con sistemas de mensajería pública (Skype, XMPP). Por lo que si la federación no la vamos a implementar con sistemas de mensajería pública, podemos utilizar sin problema alguno los certificados emitidos por nuestros servidores. Puesto que si queremos federarnos con otras empresas con Lync, únicamente debemos enviarle nuestro certificado raíz y no tendremos problemas para conectar ambas implementaciones de Lync vía federación. Pero si queremos olvidarnos de enviar el certificado raíz y además, queremos federarnos con cualquier sistema de mensajería pública (compatible) entonces si necesitamos certificados emitidos por una entidad pública.
Los servidores o vía Firewall que debemos exponer directamente son el EDGE y un reverse-proxy para publicar los servicios web de Lync (meet.dominio.com, dialin.dominio.com, lyncdiscover.dominio.com, lync.dominio.com). Yo recomiendo siempre adquirir dos certificados, uno para el EDGE del tipo SAN con los tres nombres obligatorios que debe tene el EDGE:
- Servicio de Acceso: sip..dominio.com
- Servicio de Conferencia: webconf.dominio.com
- Servicio de A/V: av.dominio.com
El resto de registros DNS que deben encontrar el EDGE con del tipo SRV:
_sip._tls.dominio.com SRV service location:
priority = 1
weight = 100
port = 443
svr hostname = sip.dominio.com
_sipfederationtls._tcp.dominio.com SRV service location:
priority = 0
weight = 0
port = 5061
svr hostname = sip.dominio.com
_xmpp-server._tcp.dominio.com SRV service location:
priority = 1
weight = 100
port = 5269
svr hostname = sip.dominio.com
Como vemos el FQDN del SVR HOSTNAME siempre es el mismo SIP.DOMINIO.COM (cada uno puede configurarlo como considere), de tal forma que el nombre del certificado SAN emitido para el EDGE será suficiente. De esta forma podemos federarnos con sistemas de mensajería pública o la autoconfiguración del cliente Lync sin necesidad de adquirir ningún otro certificado. Muchos proveedores de certificados, ya nos ofrecen packs específicos para Comunicaciones Unificadas, por ejemplo DigiCert, que nos ofrece un certificado SAN con 4 nombres por xxx €
Yo utilizo DigiCert por su rapidez (en menos de 15 minutos tengo los certificados disponibles), la flexibilidad y soporte técnico. Pero vamos, existen infinidad de proveedores para adquirir vuestros certificados.
Por último debemos adquirir otro certificado (pero también podemos añadir el nombre wildcard en el certificado SAN) del tipo wildcard para publicar vía reverse-proxy (TMG, F5, KEMP) los distintos servicios Web de Lync (Conferencias, ABS, etc..), Exchange (Contactos de Exchange, Histórico de conversaciones, Presencia en función nuestra disponibilidad del calendario, etc..) y WAC (para poder publicar nuestras presentaciones de PowerPoint). Además, si adquirimos un certificado wildcard podemos publicar todos los servicios web que sean subdominios del dominio principal de primer nivel. Por ejemplo, si tenemos que publicar SharePoint, Exchange (OWA), Página Web con HTTPS, etc.. podemos hacerlo con el mismo certificado:
- intranet.dominio.com
- mail.dominio.com
- blog.dominio.com
- aplicacion.dominio.com
Comentaros también que como sabéis ahora el SharePoint, Exchange y Lync utilizan las Office Web Apps para mostrar en web los distintos documentos de Office. Por lo que si preparamos el servidor de WAC podemos utilizar el certificado wilcard (*.dominio.com) para publicar el servidor con el FQDN office.dominio.com para todos los servicios.
De esta forma, el cliente habrá invertido en un certificado que podrá reutilizar para cualquier otro servicio web que requiera cifrado. Como los servicios expuestos a internet para Lync solo serían el EDGE y los servicios web del Front-END o Director pero mediante un reverse-proxy , solo debéis adquirir un certificado por servicio no por servidor. Si tenéis un pool de servidor EDGE, todos deben tener el mismo certificado externo porque todos gestionarán el mismo dominio, y para los servidores Front-END o Director será el reverse-proxy quien debe tener el certificado. Si tenemos un reverse-proxy en alta disponibilidad, es lo mismo que el EDGE, el mismo certificado debe estar instalado en todos los servidores o appliance de reverse-proxy.
Como os había comentado, los certificados para los servidores que no tengan acceso directo a internet, podéis (desde mi punto de vista debéis) utilizar los certificados de vuestra entidad certificadora interna (
Windows Server 2012, Instalación de una CA). Por defecto todos los equipos del dominio tendrán el certificado raíz de vuestra CA como CA de confianza, por lo que no tendréis problemas de confianza en los certificado emitidos para vuestros servidores.
Como resumen, con un certificado SAN con tres nombres para el EDGE y un certificado wildcard para la publicación de servicios web cubriréis toda la implementación de Lync y más servicios.
Espero haber podido aclarar un poco más el tema de los certificado para Lync. Por último os dejo aquí un pequeño resumen de la compatibilidad de los certificados wildcard para nuestra implementación de Lync y la integración con Exchange en cuanto a la Mensajería Unificada:
Aquís os dejo algunos artículos publicamos con anterioridad que vienen a cuento de este artículo y os podrían ser de utilidad:
Espero que os sea de utilidad!!!
Os adjunto los Open Specifications Posters en PDF
ExchangeOpenSpecPoster.pdf
