Microsoft Lync Server
Header

Lync Server: Modificar el tiempo de validez de un certificado de usuario

septiembre 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Hace ya algún tiempo, había publicado un artículo que me había parecido muy interesante sobre la diferencia entre deshabilitar un usuario en el Directorio Activo y no en Lync: Deshabilitar un usuario en el Directorio Activo y en Lync

Aqui os dejo el texto incial del artículo para que veáis de que se trata: 

​En más de una ocasión os habréis encontrado con la situación de tener que deshabilitar un usuario en el Directorio Activo que tiene cuenta de Lync. Sin embargo esto no evita que el usuario pueda iniciar sesión en Lync durante un periodo máximo de 6 meses, y siempre en función de otros factores. Esto puede llegar a ser un problema muy importante para las organizaciones, puesto que el usuario  podría estar realizando llamadas a la PSTN sin control o incluso hablar con gente de la organización y poder sacar información de la empresa sin que nadie de cuenta de ello. 
 
Caducidad_certificados_1.png
 
Pues ahora vamos a ver como podemos manejar el tiempo de expiración de un certificado de usuario emitido por nuestro servidor de Lync. Por defecto, como os había comentado los certificados tienen una fecha de expiración de 6 meses, esto en algunos casos puede ser excesivo, por lo que debemos poder manejar estas ventanas temporales de alguna forma.  Y por supuesto que podemos hacerlo, para ello tenemos el siguiente cmdlet para establecer el tiempo máximo de duración de un certificado de usuario:
 
Set-CsWebServiceConfiguration –DefaultValidityPeriodHours
 
Pues si queremos que en vez de 6 meses, los certificados caduquen a los 90 días el valor de DefaultValidityPeriodHours deberá ser de 2160:
 
Set-CsWebServiceConfiguration –DefaultValidityPeriodHours 2160
 
A partir de este momento, todos los usuarios que inicien sesión en Lync recibirán un certificado de usuario por parte del servidor con una duración máxima antes de caducar de 90 días. Pero claro, que ocurrirá con los usuarios que un día antes de este cambio ya se las había emitido el certificado, pues que seguirán utilizando este certificado hasta que caduque. Y claramente, esto no es lo que queremos, para ello lo que podemos hacer es revocar todos los certificados de usuarios, y la próxima vez que los usuarios inicien sesión ya tendrán el nuevo certificado con una caducidad de 90 días. Para ello tenemos el siguiente cmdlet que revocará todos los certificados asignados a los usuarios:
 
Get-CsClientCertificate | Revoke-CsClientCertificate
 
También podemos establecer el valor mínimo y máximo de validez de un certificado pero con las siguientes limitaciones:
  • Mínimo –> 1 Hora
 Caducidad_certificados_2.png
  • Máximo –> 8760 Horas (1 año)
 Caducidad_certificados_3.png

Para establecer estos valores, debemos utilizar los siguientes cmdlets:
 
Set-CsWebServiceConfiguration –MinValidityPeriodHours 1

 

Set-CsWebServiceConfiguration –MaxValidityPeriodHours 2880
 
Así que ya sabéis, que si necesitáis cambiar la fecha de caducidad de vuestros certificados de usuario, dos comandos y todo arreglado.
 
Espero que os sea de utilidad!!!

Certificados SAN o Wildcard para nuestra implementación de Lync Server

agosto 26th, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Continuando con este artículo que había publicado hace unos meses (¿Qué certificados necesitamos para Lync?), aquí os dejo una tabla resumen de la utilización de un certificado wildcard (para asegurar un dominio y todos sus subdominios de primer nivel) y SAN (Nombres alternativos del sujeto que permiten proteger varios hostnames con un único certificado SSL)

Certificado_Comodin_Compatibilidad.jpg 
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
    • Nombres de dominio
    • FQDN del Pool
    • FQDN de cada servidor
    • Servicios Web (URLs: meet, dialin, admin, etc…)
  • EDGE
    • FQDN del servidor (certificado interno)
    • FQDN del Pool (certificado interno)
  • Director
    • FQDN del Pool
    • FQDN de cada servidor
    • Servicios Web (URLs: meet, dialin, admin, etc…)
  • WAC
    • URL de los servicios Web del 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 €
Certificado_Comodin_Compatibilidad_1.jpg 
 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:
Certificado_Comodin_Compatibilidad_2.jpg 
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!!!

DigiCert ha renovado DigiCertTool v 2.3.1

mayo 19th, 2013 | Posted by Santiago Buitrago in Lync Server | Seguridad - (0 Comments)

​Seguro que muchos de vosotros conocéis DigiCertTool, una utilidad de DigiCert para gestionar nuestros certificados. En estos días la han actualizado y liberado para su descarga: DigiCert® Certificate Utility for Windows.

Para mi se ha convertido en una estupenda herramienta de gestión de certificados, y con esta actualización han habilitado alguna que otra función nueva que nos facilitará la gestión de los certificados. Lo más notable a simple vista es que le han cambiado el aspecto:

Antes

digicert_tool_new_1.png

Ahora

digicert_tool_new_2.png

Las opociones aunque las hayan movido de sitio siguen siendo muy parecidas, así que me voy a centrar en lo que me ha parecido más interesante. Ahora tenemos la posibilidad de iniciar sesión en DigiCert directamente desde DigiCertTool:

digicert_tool_new.png
 
Una vez que hemos iniciado sesión podemos ver nuestras solicitudes pendientes o completadas, además de poner subir el CSR (Creación de CSR para Lync de forma sencilla) o instalar el certificado directamente en el servidor desde el cual hemos solicitado el CSR:
digicert_tool_new_3.png
Aun no lo he podido probar, más bien porque no he tenido la necesidad de hacerlo, pero se supone que esto nos facilitará la tarea de solicitud e instalación de nuestros certificados. También han añadido la posibilidad de chequear el Code Signing de las aplicaciones, dlls, ocx, etc..(siempre es muy curiosos ver los resultados…)
digicert_tool_new_4.png
Ejemplo: TeamViewer
digicert_tool_new_5.png
Por último me ha gustado la nueva forma de comprobar los distintos certificados que ya tenemos instalados, para ello vamos a la opción SSL, seleccionamos el certificado que queremos verificar y pulsamos en Test Key
digicert_tool_new_6.png
digicert_tool_new_7.png
Otras de las opciones interesantes que no nueva, es la de Tools, que a buen seguro será la que más uso le deis puesto que tiene opciones muy interesantes como la comprobación de certificados (Certificate Installation Checker), etc..
digicert_tool_new_8.png
 
Para chequear la instalación de nuestro u otro certificado, pulsamos en Check Install y cubrimos las distintas opciones que tenemos disponibles en la siguiente pantalla y pulsamos en Query Server
digicert_tool_new_9.png
Y en cuestión de segundos nos mostrará el resultado
digicert_tool_new_10.png
Si no la habíais utilizado hasta ahora, creo que os ayudará con la gestión de vuestros certificados, y si ya estáis familiarizados con la versión anterior esta os gustará seguro
 
Espero que os sea de utilidad!!!

, ,

1 Edge, 1 Certificado SAN para un Dominio, Múltiples Dominios SIP y Federaciones

mayo 6th, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Voy a empezar este artículo con una pregunta: ¿Se pueden federar múltiples dominios SIP con un único certificado SAN (dominio único) en nuestro EDGE? Pues la respuesta es ……. SIII!!!

Este suele ser un esquema muy común de una implementación de Lync On Premise con federaciones con IM Públicos, Office 365 y On Premise.

Imagen a tamaño real
Federaciones_Lync_OP-OL.jpg
Para poder federarnos tanto con otras implementaciones de Lync (On Premise u Office 365) como cono sistemas de IM Públicos es necesario configurar los registros DNS  correspondientes para que encuentren nuestro EDGE en el cual tenemos el certificado público para nuestro dominio. Vamos a verlo más en detalle e imaginemos que tenemos el siguiente dominio: asirsl.com y un edge con un certificado SAN con los siguientes nombres alternativos pero con un dominio único:
  • SIP.ASIRSL.COM
  • AV.ASIRSL.COM
  • WEBCONF.ASIRSL.COM
  • EDGE.ASIRSL.COM (no es necesario, lo utilizo para identificarlo en la federación de MSFT pero podemos hacerlo con el fqdn SIP.ASIRSL.COM)
Ahora si quisieramos federarnos con MSFT (Skype) debemos solicitarlo desde la siguiente URL: Microsoft Lync Server Public IM Connectivity Provisioning. Para ello tenemos que agregar el dominio que queremos federar y especificar el FQDN del EDGE en donde tenemos los dominios a federar por nuestra parte
Multiples_Federaciones_Edge_1.png
por último necesitamos crear el siguiente registro DNS de tipo SRV obligatorio:
 
_sipfederationtls._tcp.asirsl.com       SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.asirsl.com
 
Por supuesto necesitamos contar con un certificado público para completar la federación, sino nunca os funcionará la federación.  Si ahora queremos federarnos con sistemas XMPP como por ejemplo Google, debemos disponer de un certificado público igualmente (el mismo) y crear un registro DNS de tipo SRV obligatorio:
 
_xmpp-server._tcp.asirsl.com    SRV service location:
          priority       = 1
          weight         = 100
          port           = 5269
          svr hostname   = sip.asirsl.com
 
Aquí os dejo algunos artículos que había escrito en su momento por si queréis utilizarlos de apoyo:

Con estas configuraciones tendríamos  completadas ambas federaciones con nuestro dominio SIP, ahora bien, que ocurre si queremos que nuestro Lync server administre más de un dominio SIP y no queremos invertir en más certificados, aquí os muestro los pasos a seguir para poder configurarlo:

1. Configurar dominios adicionales en el generador de topologías de Lync Server

Multiples_Federaciones_Edge_2.png
Una vez añadidos los dominios SIP adicionales, automáticamente se crearán las direcciones simples para las reuniones online: https://meet.dominiosip.xxx de cada dominio.

2. Creación en el dominio de los sufijos UPN de los nuevos dominios SIP para asignar posteriormente a los usuarios creados en el Active Directory, de tal forma que su dirección SIP en Lync coincida con su nombre de usuario en el Active Directory

Multiples_Federaciones_Edge_3.png
3. Creamos los usuarios en el Directorio Activo y le asignamos el sufijo UPN creado para su dominio

Multiples_Federaciones_Edge_4.png

4. Habilitamos el usuario en Lync y como dirección SIP elegimos la opción de Use the user principal name (UPN)

Multiples_Federaciones_Edge_6.png
Multiples_Federaciones_Edge_5.png
5. Configurar los nombres de dominio que hemos añadido en los certificados de los Front-END. Esto es opcional si queremos utilizar únicamente Lync desde fuera de la organización.

6. Federaciones: ahora viene lo  más interesante, la posibilidad de federar los nuevos dominios SIP utilizando únicamente el certificado que tenemos para nuestro dominio principal, en mi caso ASIRSL.COM. Voy a mostraros los pasos a seguir en función del tipo de federación:

Federación con MSFT: Necesitamos crear un registro DNS de tipo SRV para el nuevo dominio de la siguiente forma, utilizaremos el dominio traimer.es como ejemplo:

_sipfederationtls._tcp.traimer.es       SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.asirsl.com

Como podéis ve, lo que hacemos es especificar que el srv hostname sea el EDGE que tenemos para el dominio ASIRSL.COM, de tal forma que le presentará el certificado que ya tiene asignado. El  certificado es un de una CA Pública por lo que no le generará error alguno para poder validarlo, y se puede utilizar sin problema. Cuando los servidores de MSFT traten de resolver el registro _sipfederationtls._tcp.traimer.es se conectarán a nuestro EDGE y en función de nuestra configuración se permitirá o no la federación con MSFT. Por supuesto debemos previamente solicitar la federación a MSFT del nuevo dominio (traimer.es), para ello debemos acceder a Microsoft Lync Server Public IM Connectivity Provisioning y añadir el nuevo dominio traimer.es utilizando el mismo Access Edge Server que ya tenemos para el dominio ASIRSL.COM

Multiples_Federaciones_Edge_7.png

Una vez que hayamos actualizado la configuración de la federación con MSFT, en unos días nos llegará un correo similar a este confirmado la federación, por lo que tendremos que probarlaMultiples_Federaciones_Edge_8.png

Ahora iniciamos el cliente de Lync con una cuenta del dominio traimer.es y tratamos de contactar con un usuario de Skype (migrado de MSN)

un_certificado_multiples_federaciones_3.png

un_certificado_multiples_federaciones_6.png

un_certificado_multiples_federaciones_7.png

Como vemos funciona perfectamente, podemos ver la presencia desde ambos clientes de mensajería, mantener conversaciones de IM y Audio.

Federación con Google: Para federarnos con sistemas XMPP y en este caso con Google para utilizar GTalk  es más sencillo todavía, debemos crear el siguiente registro DNS de tipo SRV:

_xmpp-server._tcp.traimer.es   SRV service location:
          priority       = 1
          weight         = 100
          port           = 5269
          svr hostname   = sip.asirsl.com

Como podéis apreciar el srv hostname sigue siendo el mismo!!! Ahora solo toca agregarnos mutuamente como contactos en GMAIL y Lync para completar la "federación". Una vez completados estos pasos, ya podemos ver la disponibilidad de los usuarios de GMAIL

Multiples_Federaciones_Edge_9.png

Federación con otro Lync Server On Premise: Esta es la federación más sencilla y habitual, podemos hacerlo de dos formas o bien de forma explícita añadiendo el dominio desde la opción de dominio federado y poniendo como  Servicio perimetral de Acceso el FQDN del EDGE de ASIRSL.COM que es quien tiene el certificados público.

un_certificado_multiples_federaciones_10.png

Y como previamente ya teniamos creado el registro SRV para la federación con MSFT, solo debemos asegurarnos de que nuestro servidor lo tenemos habilitado para el descubrimiento del partner federado si queremos configurar la federación de esta forma

_sipfederationtls._tcp.traimer.es       SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.asirsl.com

Multiples_Federaciones_Edge_10.png

Ahora agregamos desde nuestra cuenta de Lync un nuevo usuario de Lync buscándolo por su dirección SIP y ya podremos ver su presencia y utilizar todas las funcionalidades habilitadas mediante este tipo de federación
un_certificado_multiples_federaciones_9.png

Federación con Office 365: solo debemos agregar como dominio permitido para la federación al dominio traimer.es y mediante la resolución de nombres de dominio (otra vez el registro SRV (_sipfederationtls._tcp.traimer.es) podremos completar la federación.

Como vemos podemos utilizar un único certificado (para un solo dominio: asirsl.com) público para federarnos con otros sistemas de IM Público, Lync o XMPP. Y si queremos utilizar la autoconfiguración del cliente para que los usuarios del nuevo dominio SIP no tengan que configurar el cliente, debemos crear el siguiente registro DNS de tipo SRV:

_sip._tls.traimer.es   SRV service location:
          priority       = 1
          weight         = 100
          port           = 443
          svr hostname   = sip.asirsl.com

Como siempre el srv hostname será el FQDN de EDGE que tiene el certificado público, y con esto más que suficiente para iniciar sesión sin configurar el cliente. Ahora bien, si queremos utilizar los distintos servicios Web de Lync o Exchange (Mobile en Autodiscover, ABS, EWS) sí que vamos a necesitar un certificado SAN con todos los nombres de dominio, de tal forma que el navegador o app no os muestre el típico error de certificado inválido porque el nombre del certificado no coincide con el nombre del sitio. Pero ahí, lo suyo siempre es tener un certificado SAN con los nombres alternativos de los otros dominios, pero del tipo wildcard (ejemplo: *.traimer.es, *.asirsl.com).

Aquí os dejo un artículo que había escrito en su momento sobre los certificados que se necesitaban para una implementación básica de Lync: ¿Qué certificados necesitamos para Lync? También comentaros que en las conferencias no tendréis problemas con el certificado del dominio ASIRSL.COM para compartir las presentaciones de PowerPoint , puesto que si el certificado es público no tendréis problemas por conectaros a la URL del WAC (ejemplo: office.asirsl.com). Puesto que como no se visualiza "nunca" la URL a la que se conecta desde el cliente Lync o el Lync Web App "nadie" sabrá que certificado se está utilizando. Pero aquí lo importantes es que se conecten de forma transparente sin que os alerta de alguna forma, y esto es viable con el certificado que utilicemos del dominio ASIRSL.COM en nuestro proxy inverso.

Os recuerdo que siempre he comentado que esta configuración es para las conexiones que se realicen desde fuera de la zona de seguridad de la empresa, siempre que lo hagamos desde dentro de la organización y utilicemos certificados emitidos por nuestra CA debemos realizar ciertas modificaciones (esto lo dejamos para otro artículo)

Espero que os sea de utilidad!!!

, , ,

Creación de CSR para Lync de forma sencilla

abril 8th, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Un CSR (Certificate Signing Request) es la petición de certificado que se envía a la autoridad de certificación. Mediante la información contenida en el CSR la autoridad de certificación puede emitir el certificado una vez realizadas las comprobaciones que correspondan. Dicho esto, vamos a ver un ejemplo práctico. Cuando instalamos Lync vamos a necesitar una serie de certificados para los distintos servicios que se manejan en los distintos roles de Lync. En este caso vamos a ver algo muy concreto, los que necesitamos para el Front-END y el EDGE. Para el EDGE necesitamos un certiifcado SAN (nombre alternativos al principal), en una instalación típica solemos tener los siguientes nombres:

sip.asirlab.com

av.asirlab.com

webconf..asirlab.com

edge.asirlab.com (lo utilizo para las federaciones)

Para estos cuatros nombres podemos solicitar un certificado SAN, primero necesitamos crear el CSR que enviaremos posteriormente a nuestro proveedor de certififcados para que pueda emitirlo. Debemos antes de nada descargarnos la utilidad de la página de Digicert: DigiCertUtil

Ahora debemos ejecutarla y pulsamos en Create CSRCSR_Certificados_2.jpg

Y empezamos a cubrir los datos que nos solicita

CSR_Certificados_4.jpg

Como vemos he añadido los tres nombres como alternativos al nombre principal del certificado, ahora pulsamos en Generate y nos creará el CSR

CSR_Certificados_5.jpg

Ahora pulsamos en Save to File y lo guardamos listo para enviárselo a nuestro proveedor de certificados.
CSR_Certificados_6.jpg

CSR_Certificados_7.jpg

Ahora este fichero se lo enviamos nuestro proveedor de certificados, y nos devolverá un fichero .cer que nos permitirá completar la solicitu del certificado. Esto se debe completar desde el mismo servidor desde el cual se ha creado el fichero CSR, puesto que se ha creado una clave privada que se almacena temporalmente hasta que se enlace con la clave pública que nos enviará la CA que ha emitido el ceritificado. El archivo .cer incluye esta clave pública y mediante la importanción del fichero en el mismo servidor, crearemos el certificado X.509 completamente funcional.

Abrimos el DigiCertUtility y pulsamos en Import

CSR_Certificados_9.jpg
Ahora pulsamos en Browse y seleccionamos el .cer que debemos tener alojado en nuestro para ser importado

CSR_Certificados_8.jpg

Antes de importar el certificado podemos verlo pulsando en View Certificate, y es conveniente escribir un nombre descriptivo para identicar el certificado cuando tenemos que seleccinarlo

CSR_Certificados_10.jpg

y como se puede apreciar aun no tiene la clave privada puesto que no hemos finalizado el proceso

CSR_Certificados_14.jpg

Una vez que pulsemos en finalizar y se importará el certificado

CSR_Certificados_11.jpg

Ahora como vemos tenemos el certificado importado y vemos algunas características del mismo

CSR_Certificados_12.jpg

Si seleccionamos el certificado importado y pulsamos en View vemos las propiedades del certificado, y como vemos ya tenemos el certificado con su clave privada.

CSR_Certificados_13.jpg

Ahora solo quedaría asignar el certificado a nuestro Lync y podemos hacerlo directamente desde la herramienta gráfica para ello, abrimos la consola de Lync Server Deployment Wizard – Instalar o Actualizar Lync Server – Solicitar, Asignar o Renovar Certificados

CSR_Certificados_15.jpg

seleccionamos el ámbito en el cual vamos a asignar el certificado (Interno o Externo) y pulsamos en Assign,

CSR_Certificados_16.jpg

Pulsamos en Siguiente

CSR_Certificados_17.jpg

Seleccionamos el certificado que hemos importado anteriormente y continuamos el asistente hasta el final y tendremos el certificado asignado a nuestro EDGE

CSR_Certificados_18.jpg

Ya veis que resulta muy sencillo la creación del CSR desde la utilidad de DigiCertUtil, sino la conociais espero que os haya sido de utilidad este artículo!!!

, ,