¿Qué certificados necesitamos para Lync?

En la fase de planificación de nuestra infraestructura, siempre hay un punto que hace referencia a los certificados que debemos adquirir. Debemos tener muchas cosas en cuenta, pero una básica son que servicios vamos a publicar y con que nombre. Todos sabéis que el nombre del certificado debe coincidir con el nombre del servicio a publicar, sino no funcinarán correctamente o directamente no funcionarán los distintos servicios. Seguro que en alguna ocasión habéis visto esta alerta en vuestro navegador.

En este caso el único problema que tenemos es que el servidor tiene asignado un certificado con un nombre diferente al que nosotros hemos tratado de conectarnos a través de nuestro navegador, y nos avisa de que podemos estar visitando un sitio diferente al que realmente queremos. O bien que estamos utilizando un certificado privado (emitido por nuestra CA en Windows) y no tenemos el certificado raiz instalado en nuestro equipo. Esto no quiere decir que el certificado no esté realizando su función que es la de cifrar el tráfico, pero el nombre que tiene no concuerda con el nombre de la URL que estamos visitando. De ahi que no es solo una cuestión puramente de seguridad, sino también de confianza. Si tenemos un servicio público al que se tienen que conectar nuestros clientes y les aparece esta advertencia, desde luego nuestra imagen como empresa quedaría por lo menos en entredicho. Además a día de hoy un certificado simple tiene un coste inferior a 80€ / año, por lo que no es una cuestión económica el no tener un certificado público.

Comentado esto, vamos a centrarnos en que debemos tener en cuenta a la hora de adquirir un certificado para nuestras implementaciones de Lync. Básicamente yo recomiendo siempre dos certificados: SAN y WILDCARD. Estos certificados serían para servicios diferentes, el certificado SAN para nuestros servidores EDGE y el Wildcard para nuestros Front-END y sus servicios Web. Como todos sabemos los nombres de los servicios que estamos publicando en el EDGE suelen ser los siguientes:

WEBCONF.ASIRSL.COM

AV.ASIRLAB.COM

SIP.ASIRLAB.COM

EDGE.ASIRSL.COM (opcional)

Esto son los nombres que debería tener nuestro certificado SAN (Subjet Alternate Name), de manera que podamos instalarlo en nuestros servidores EDGE y contengan el nombre de todos los servicios que vamos a publicar y en un solo certificado. Siempre estoy hablando de los certificados asignados a las interfaces externas, por lo que son certificados de una entidad certificadora pública (Verisign, Digicert, Thawte). Con esto tendríamos nuestro servidores/es EDGE correctamente configurados en cuanto al certificado se refiere, siempre y cuando los nombres de los certificados se correspondan con los nombres de los servicios (lo doy por hecho).

Ahora vamos a ver los certificados que necesitamos para el resto de servicios y que no pasan por el EDGE, sino por el Front-END o Director. En estos roles publicamos los distintos servicios con los siguientes nombres “por defecto”:

lyncdiscover.asirlab.com

lync.asirlab.com o pool.asirlab.com (opcional según el nombre que hayamos configurado)

dialin.asirlab.com

meet.asirlab.com

Estos servicios se suelen publicar a través de un ISA Server, TMG o similar como reverse proxy, y es a ese servidor a cual le tenemos que instalar el certificado externo que adquiramos. El certificado que yo recomiendo siempre es un WILDCARD, porque os permitirá posteriormente utilizarlo para publicar más servicios que los de Lync, por ejemplo: OWA, SharePoint, CRM, WAC y cualquier otra URL del mismo dominio con el siguiente FQDN: loquesea.asirlab.com. De esta forma podéis aprovechar el certificado para publicar más servicios que exclusivamente los de Lync. Y si por ejemplo hoy publicais el meet.asirlab.com únicamente y dentro de 6 meses queréis tener disponible el dialin.asirlab.com o lyncdiscover.asirslab.com ya no tendréis que adquirir más certificados, de cualquier otra forma si. Aqui también podemos disponer de un certificado SAN, pero el coste del certificado con los 3 nombres obligatorios para el EDGE más los dos del Front-END tendrá un sobre coste superior a tener un WildCard y un SAN. Además de que para cada servicio completamente diferenciado es recomendable tener distintos certificados, pero eso ya es otro tema.

Ahora bien, si nuestra infraestructura cuenta con un TMG para publicar las distinas URL, yo recomiendo que el certificado que se instale a los servidores sea de vuestra Entidad Certificadora Privada, puesto que os permite solicitar tantos certificados como queráis sin tener que preocuparos por el coste. Si os olvidáis de algún nombre en la fase piloto, solo tenéis que volver a solicitarlo y no tendréis problema de costes económicos. Tened en cuenta que el TMG presentará en el certificado público al exterior pero hacia los servidores internos se conectará con el certificado interno, y que además el TMG al estar en el dominio ya tiene el certificado raiz de confianza instalado y no tendréis problemas con la publicación de cualquier servicio Web de Lync. Con el certificado Wildcard (*.asirlab.com) podéis publicar con el mismo listener de TMG más servicios como he comentado anteriormente. Esto también es aplicable al EDGE, en su interfaces interna puede tener tener un certificado de nuestra CA Privada y funciona sin problema.

Esto siempre y cuando tengáis un solo dominio SIP, si tenéis varios dominios SIP y queréis tener certificados públicos, el certificado debe contener todos los nombres FQDN de todos los dominios. Como he comentado yo recomiendo hacerlo de esta forma, es de las más económicas, permite la reutilización del certificado para otras publicaciones y nos permite publicar distintos servicios de Lync que inicialmente no lo habíamos hecho sin coste adicional. Todo esto tiene sus matices, pero es cuestión de tener claro que servicios vamos a publicar, que nombres tendrán esos servicios y como se van a publicar al exterior.

Si además implementamos los servicios de UM de Exchange, el certificado que debemos utilizar es también uno de nuestra Entidad Certificadora. Como nuestros servidores de Lync forman parte del dominio, no tendrán problemas con la validación del certificado que ambos se están presentando para la autenticación de servicios. El certificado del servidor Exchange para el ROL de UM debe tener como nombre común el nombre FQDN del servidor sino, no funcionará

Y por último para la integración del OWA con Lync, es más de lo mismo pero teniendo en cuenta algo muy sencillo. Cuando creemos nuestras aplicación de confianza el nombre debe ser el mismo que el nombre común que hemos configurado en el certificado asignado en Exchange para la integración con Lync

Sino es asi podréis encontraros de que todo está correctamente instalado, configurado y publicado pero … error!!! (esta captura representa uno de los posibles errores)

Como véis es muy sencillo, pero es cuestión de tener claras nuestras necesidades y el resto es aplicar el conocimiento que ya tenéis sobre Lync y Certificados. Si no queremos utilizar certificados públicos podemos hacer exactamente lo mismo con nuestra CA Privada, pero al resto de usuarios que no tengan las máquinas en nuestro dominio debemos pasarles nuestro Certificado Raiz para que lo instalen en el contenedor adecuado de sus equipos

Pero si queréis federar vuestro Lync con Microsoft, Google, etc.. debéis disponer de certificados públicos en vuestro EDGE. Si queréis federaros con otras compañias y no tenéis certificados públicos únicamente debéis “intercambiar” vuestras CA.

Aqui os muestro varias capturas de pantalla sobre un certificado WildCard conectándome a distintas URLs y otro SAN:

WildCard: nos conectamos a https://soporte.asirsl.com