Solicitar e configurar um certificado do proxy HTTP reverso

Tópico modificado em: 2012-07-15

O servidor de proxy reverso típico tem uma autoridade de certificação (AC) pública e a infraestrutura da AC interna que é usada para os requisitos do Enterprise quando os certificados são necessários. O Microsoft Lync Server 2010 pode usar uma infraestrutura de chave pública (PKI) do Enterprise para todos os propósitos internos, se você possuir uma implantada. Ou, você pode usar os certificados de autoridade de certificação públicos para todos os usos, tanto internos quanto externos. Se você pretende usar certificados de AC internos ou públicos, o proxy reverso precisará do certificado de raiz (e quaisquer certificados intermediários) da AC pública e o certificado raiz (e quaisquer certificados intermediários) da AC interna. Você deve instalar os certificados raiz e quaisquer certificados de AC intermediários no servidor proxy reverso. Consulte a documentação do seu proxy reverso para determinar como a raiz e os certificados intermediários devem ser carregados no proxy reverso.

Você deve instalar um certificado público do tipo Servidor Web no seu servidor de proxy reverso. Um certificado do tipo Servidor Web garantirá que o certificado possa estabelecer comunicação corretamente com as solicitações do cliente. O nome de requerente (SN) do certificado público será o nome externo dos serviços Web externos do Servidor Front-End ou Pool de Front-Ends. Nos exemplos utilizados para a Arquitetura de referência em Planejando o acesso de usuários externos, o Servidor Front-End ou Pools de Front-Ends FQDN externo é webext.contoso.com. A definição do nome alternativo para o requerente (SAN) do certificado deve conter os nomes de domínio totalmente qualificados (FQDNs) dos serviços Web externos publicados de cada pool que é a página inicial para os usuários habilitados obterem o acesso remoto. Um ouvinte separado e um certificado devem ser configurados para os FQDNs dos serviços Web externos de todos os Diretor ou Pool de diretores que serão utilizados dentro dessa infraestrutura de borda. Um exemplo de requerente Diretor ou Pool de diretores e nome alternativo para o requerente para o certicate seria webdirext.contosom. O nome alternativo para o requerente também deve conter a URL de reunião simples, a URL de discagem simples e, se você estiver implantando aplicativos móveis e planeja usar a descoberta automática, a URL do serviço de Descoberta Automática externa, conforme exibido na tabela a seguir. Os SANs da URL simples e da descoberta do Lync permanecerão os mesmos que o Servidor Front-End, conforme exibido na tabela.

	Valor	Exemplo
Nome da entidade	FQDN do pool	webext.contoso.com
Nome alternativo da entidade	FQDN do pool	webext.contoso.com
Nome alternativo da entidade	URL simples de reunião Observação: Todas as URLs simples de reunião devem estar no nome alternativo da região. Cada domínio SIP deve ter pelo menos uma URL simples de reunião ativa.	meet.contoso.com
Nome alternativo da entidade	URL simples de discagem	dialin.contoso.com
Nome alternativo da entidade	URL de Serviço Descoberta Automática Externo	lyncdiscover.contoso.com

Observação:

Se sua implantação interna consiste em mais de um servidor Standard Edition ou pool de Front-End, você deve configurar regras de publicação na Web para cada FQDN de web farm externo e será necessário um ouvinte da web e certificado para cada um, ou você deve obter um certificado cujo nome alternativo da entidade contém os nomes usados por todos os pools, atribuí-lo a um ouvinte da web e compartilhá-lo entre várias regras de publicação na web.