Solicitar y configurar un certificado para el proxy HTTP inverso

 

Última modificación del tema: 2012-07-15

Los servidores proxy inversos típicos disponen de certificados que proceden de autoridades de certificación (CA) públicas y de la infraestructura de CA interna que se usan de acuerdo con los requisitos empresariales. Microsoft Lync Server 2010 puede usar una infraestructura de clave pública empresarial (PKI) para todos los fines, en caso de que tenga implementada esta infraestructura. O bien, puede usar certificados de CA públicas en todos los casos, tanto de forma interna como externa. Si desea usar certificados de CA públicas y de CA internas, el servidor proxy inverso necesita tanto el certificado raíz (así como todos los certificados intermedios) de la CA pública y el certificado raíz (así como todos los certificados intermedios) de la CA interna. Estos certificados raíz se deberán instalar, junto con los certificados intermedios, en el servidor proxy inverso. Consulte la documentación de su servidor proxy inverso para averiguar cómo se deben cargar los certificados raíz e intermedios en el servidor proxy inverso.

Debe instalar un certificado público del tipo de servidor web en su servidor proxy inverso. Estos certificados se comunican correctamente con las solicitudes de los clientes. El nombre de sujeto del certificado público (SN) será el nombre externo de los servicios web externos del Servidor front-end o del Grupo de servidores front-end. En los ejemplos usados para la Arquitectura de referencia en Planeación del acceso de usuarios externos, el nombre de dominio completo (FQDN) externo del Servidor front-end o del Grupos de servidores front-end es webext.contoso.com. La definición del nombre de sujeto alternativo (SAN) debe contener los nombres de dominio completo (FQDN) de los servicios web externos publicados de cada grupo de servidores que se use como punto de inicio para los usuarios con acceso remoto habilitado. Es necesario configurar un servicio de escucha y un certificado distinto para los FQDN de los servicios externos de todos los Director o los Grupo de directores que se vayan a usar en la infraestructura perimetral. Un ejemplo de nombre de sujeto y de nombre de sujeto alternativo de Director o de Grupo de directores para el certificado sería webdirext.contosom. El nombre de sujeto alternativo también debe contener la dirección URL simple de la reunión, la dirección URL simple de marcación y, si desea implementar aplicaciones móviles y planea usar el servicio de detección automática, la dirección URL del servicio de autodetección externo tal como se muestra en la tabla siguiente. La dirección URL simple y los SAN de Lync Discover seguirán siendo los mismos que los del Servidor front-end, tal como se muestra en la tabla.

	Valor	Ejemplo
Nombre de sujeto	FQDN del grupo de servidores	webext.contoso.com
Nombre alternativo de sujeto	FQDN del grupo de servidores	webext.contoso.com
Nombre alternativo de sujeto	URL sencilla de reunión Nota Todas las URL sencillas de reunión deben incluirse en el nombre alternativo de sujeto. Cada dominio SIP debe tener al menos una URL sencilla de reunión activa.	meet.contoso.com
Nombre alternativo de sujeto	URL sencilla de marcado	dialin.contoso.com
Nombre alternativo de sujeto	URL externa del servicio Detección automática	lyncdiscover.contoso.com

Nota

Si la implementación interna está formada por más de un servidor Standard Edition o grupo de servidores front-end, deberá configurar reglas de publicación de web para cada FQDN de la granja de servidores web externo y también necesitará un certificado y una escucha de web para cada uno o deberá obtener un certificado cuyo nombre alternativo de sujeto contenga los nombres que usan todos los grupos de servidores, asignarlo a una escucha de web y compartirlo entre las varias reglas de publicación de web.