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

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:

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.

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

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

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.

• 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.

• 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..).

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

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!!!