Suporte certificado curinga

 

Tópico modificado em: 2012-10-18

O Microsoft Lync Server 2010 usa os certificados para fornecer criptografias de comunicações e autenticação de identidade do servidor. Em alguns casos, como em publicações na web através do proxy reverso, uma entrada forte de nome alternativo da entidade (SAN) que corresponda ao nome de domínio totalmente qualificado (FQDN) do servidor apresentando o serviço não é necessária. Nesses casos, é possível usar certificados com entradas curingas de SAN (comumente conhecidos como "certificados curinga") para reduzir o custo de um certificado solicitado por uma autoridade de certificação pública e para reduzir a complexidade do processo de planejamento para certificados.

Aviso:
Para reter a funcionalidade de dispositivos de comunicações unificadas (UC) (por exemplo, telefones de mesa), você deve testar o certificado implantado com cuidado para garantir que os dispositivos funcionem adequadamente depois de implantar um certificado curinga.

Não há suporte para uma entrada curinga como nome de entidade (também conhecido como nome comum ou CN) para nenhuma função. As funções do servidor apresentadas a seguir são suportadas quando são usadas entradas curinga no SAN:

• 
  Proxy reverso. A entrada de SAN curinga é suportada por certificado de publicação de URL simples.

• 
  Diretor. A entrada de SAN curinga é suportada por URLs simples nos componentes de Web do Director.

• 
  O Servidor Front-End (Standard Edition) e o Pool de Front-Ends (Enterprise Edition). A entrada de SAN curinga é suportada para URLs simples de componentes da Web de Front-Ends.

• 
  Unificação de Mensagens (UM) do Exchange. O servidor não usa entradas de SAN quando implantado como um servidor autônomo.

• 
  Servidor de Acesso para Cliente do Microsoft Exchange Server. As entradas curinga no SAN são suportadas por clientes internos e externos.

• 
  Servidor de Acesso para Clie te Unificação de Mensagens (UM) do Exchange e Microsoft Exchange Server no mesmo servidor. As entradas curinga de SAN são suportadas.

As funções do servidor que não são abordadas neste tópico:

• Funções do servidor interno (incluindo, mas não limitado ao Servidor de Mediação, ao Servidor de Arquivamento e Monitoramento, ao Aparelho de Filial Persistente ou ao Servidor de Filial Persistente)

• Interfaces externas do Servidor de Borda

• Servidor de Borda interno

  Observação:
  Para a interface interna do Servidor de Borda, uma entrada curinga pode ser designada ao SAN e é suportada. O SAN no Servidor de Borda interno não é consultado, e uma entrada curinga de SAN tem valor limitado.

Para descrever os usos possíveis do certificado curinga, as diretrizes do certificado usadas para as Arquiteturas de Referência na documentação de Planejamento são replicadas aqui para reter a consistência. Para obter detalhes, consulte Arquitetura de referência. Conforme mencionado anteriormente, os dispositivos de UC confiam na correspondência do nome forte e falharão na autenticação se a entrada curinga de SAN estiver presente antes da entrada do FQDN. Ao seguir a ordem apresentada nas tabelas a seguir, você limita os problemas em potencial com um dispositivo de UC e entras curinga no SAN.

Configurações do certificado curinga para o Lync Server 2010

Componente	Nome de entidade	Entradas de SAN/Ordem	Autoridade de certificação (CA)	Uso avançado de chave (EKU)	Comentários
Proxy reverso	lsrp.contoso.com	lsweb-ext.contoso.com *.contoso.com	Público	Servidor	Serviço de catálogo de endereço, expansão de grupo de distribuição e regras de publicação do dispositivo IP do Lync. Nomes alternativos de entidade incluem: FQDN de serviços de Web externa O curinga substitui o SAN de reunião e de discagem, em que os URLs simples de ambos usam os formatos a seguir: <FQDN>/meet <FQDN>/dialin OU meet.<FQDN> dialin.<FQDN>
Diretor	dirpool01.contoso.net	sip.contoso.com sip.fabrikam.com dirweb.contoso.net dirweb-ext.contoso.com <hostname>.contoso.net, for example <hostname> is director01 for a Director in a pool dirpool.contoso.net *.contoso.com	Privado	Servidor	Designar os servidores e as funções a seguir ao pool de Diretores: Cada Diretor no pool ou ao Diretor autônomo quando o pool de Diretores não estiver implantado. O curinga substitui o SAN de reunião e de discagem, em que os URLs simples de ambos usam os formatos a seguir <FQDN>/admin <FQDN>/meet <FQDN>/dialin OU admin.<FQDN> meet.<FQDN> dialin.<FQDN>
Front-Ends do Enterprise Edition	pool01.contoso.net (Para um pool carregado e balanceado)	sip.contoso.com sip.fabrikam.com lsweb.contoso.net lsweb-ext.contoso.com <hostname>.contoso.net, por exemplo, <hostname> é fe01 para um servidor front-ends em um pool pool01.contoso.net *.contoso.com	Privado	Servidor	Designar aos seguintes servidores e funções no pool de salto: Front-Ends no Pool01 O curinga substitui o SAN de reunião e de discagem, em que os URLs simples de ambos usam os formatos a seguir <FQDN>/admin <FQDN>/meet <FQDN>/dialin OU admin.<FQDN> meet.<FQDN> dialin.<FQDN>
Front-Ends do Standard Edition	se01.contoso.net	sip.contoso.com sip.fabrikam.com lsweb.contoso.net lsweb-ext.contoso.com se01.contoso.net *.contoso.com	Privado	Servidor	Designar aos seguintes servidores e funções no pool de salto: O curinga substitui o SAN de reunião e de discagem, em que os URLs simples de ambos usam os formatos a seguir <FQDN>/admin <FQDN>/meet <FQDN>/dialin OU admin.<FQDN> meet.<FQDN> dialin.<FQDN>

Microsoft Exchange Server 2007 e Exchange Server 2010

Quando você instala e configura o Microsoft Exchange Server, certificados autoassinados são criados e implementados. Quando você adiciona um certificado fornecido pela autoridade de certificação ao servidor, recomendamos que você não exclua o certificado autoassinado até ter reconfigurado todos os serviços e serviços da Web para usar o novo certificado com sucesso. Caso algo não funcione corretamente, o certificado autoassinado ainda estará disponível de forma que você possa reconfigurar as configurações originais e restaurar as funções originais, embora o certificado autoassinado não habilite todos os recursos que você precisa. Isso lhe dá um tempo a mais para solucionar as configurações sem afetar todas as funções de produção.

Para obter detalhes sobre o uso de certificados no Exchange, consulte o seguinte:

• Noções Básicas Sobre Certificados Digitais e SSL: https://go.microsoft.com/fwlink/?linkid=218233&clcid=0x416

• Compreendendo Namespaces de Servidor de Acesso para Cliente: https://go.microsoft.com/fwlink/?linkid=218234&clcid=0x416

• Noções Básicas Sobre o Serviço de Descoberta Automática: https://go.microsoft.com/fwlink/?linkid=217012&clcid=0x416

Para o Microsoft Exchange Server implantado com o Unificação de Mensagens (UM) do Exchange e o servidor de Acesso para Cliente Exchange, existem quatro cenários de implantação possíveis:

• Cenário 1: o Unificação de Mensagens (UM) do Exchange e o servidor de Acesso para Cliente do Exchange são implantados em servidores diferentes, e o servidor de Acesso para Cliente é voltado à Internet.

• Cenário 2: o Unificação de Mensagens (UM) do Exchange e o servidor de Acesso para Cliente do Exchange são colocados no mesmo servidor e são voltados à Internet.

• Cenário 3: o Unificação de Mensagens (UM) do Exchange e o servidor de Acesso para Cliente do Exchange são implantados em servidores diferentes com um proxy reverso para publicação.

• Cenário 4: o Unificação de Mensagens (UM) do Exchange e o servidor de Acesso para Cliente do Exchange são colocados no mesmo servidor com um proxy reverso para publicação.

Cenário 1: Unificação de Mensagens (UM) do Exchange & servidor de Acesso para Cliente do Exchange implantados em servidores diferentes (o Servidor de Acesso para Cliente é voltado à Internet)

Componente do Microsoft Exchange	Nome de entidade	Entradas de SAN/Ordem	Autoridade de certificação (CA)	Uso avançado de chave (EKU)	Comentários
Unificação de Mensagens (UM) do Exchange Nome do servidor: exchum01.contoso.com	exchum01.contoso.com	A função UM do Exchange não deve conter uma entrada de SAN	Privado	Servidor	O servidor do UM do Exchange se comunica apenas com clientes e servidores internos. Importe um certificado raiz privado e de CA em cada servidor do UM do Exchange. Crie e designe um certificado único para cada servidor UM do Exchange. O Nome de entidade deve corresponder ao nome do servidor. É preciso habilitar a Segurança da Camada de Transporte (TLS) no servidor UM do Exchange antes de designar um certificado à função UM do Exchange. Designe esse certificado para uso no servidor de Acesso para Cliente do Exchange para integração com o Outlook Web Access e o sistema de mensagens instantâneas (IM).
Servidor de Acesso para Cliente do Exchange Servidor de Acesso para Cliente do site do Active Directory voltado à Internet Nome do servidor: exchcas01.contoso.com	mail.contoso.com	mail.contoso.com autodiscover.contoso.com *.contoso.com	Público	Servidor	O Nome de entidade e a entrada de SAN devem corresponder para dar suporte aos dispositivos de UC externos. O mail.contoso.com como nome de entidade e entrada de SAN é um exemplo de nome usado para se referir ao Outlook Web Access, ao Outlook Anywhere, ao EWS e ao Catálogo de endereços off-line. As únicas exigências são que a entrada deve corresponder ao registro de DNS e que o ExternalURL e outras entradas de serviço possam ser consultados por determinado nome. A entrada de SAN de descoberta automática é necessária para dar suporte a dispositivos de UC externos.
Servidor de Acesso para Cliente do Exchange Servidor de Acesso para Cliente do site do Active Directory não voltado à Internet Nome do servidor: internalcas01.contoso.net	internalcas01.contoso.com	internalcas01.contoso.com *.contoso.com	Privado	Servidor	O servidor de Acesso para Cliente do site do Active Directory não voltado à Internet se comunica apenas com clientes e servidores internos. O servidor de Acesso para Cliente do site do Active Directory voltado à Internet realiza proxies de comunicação com esse servidor de Acesso para Cliente se a solicitação vem de um usuário ou serviço em consulta a serviços (por exemplo, caixa de correio) e que é hospedado nesse site do Active Directory. Os serviços de EWS e de Catálogo de endereços off-line no site do Active Directory não voltado à Internet são configurados para usar o certificado implantado. Esse certificado pode vir da CA privada interna. O certificado raiz para a CA privada deve ser importado ao armazenamento Certificados raiz confiáveis de terceiros servidor de Acesso para Cliente do site do Active Directory voltado à Internet.

Cenário 2: Unificação de Mensagens (UM) do Exchange & servidor de Acesso para Cliente do Exchange colocados no mesmo servidor (voltados à Internet)

Componente do Microsoft Exchange	Nome de entidade	Entradas de SAN/Ordem	Autoridade de certificação (CA)	Uso avançado de chave (EKU)	Comentários
Unificação de Mensagens (UM) do Exchange Nome do servidor: exchcas01.contoso.com	exchcas01.contoso.com	A função UM do Exchange não deve conter uma entrada de SAN	Privado	Servidor	O servidor do UM do Exchange se comunica apenas com clientes e servidores internos. Importe um certificado raiz privado e de CA em cada servidor do UM do Exchange. É preciso habilitar a TLS no servidor UM do Exchange antes de designar um certificado à função UM do Exchange. Designe esse certificado para uso no servidor de Acesso para Cliente do Exchange para integração com o Outlook Web Access e o sistema de IM.
Servidor de Acesso para Cliente do Exchange e Servidor de Acesso para Cliente do site do Active Directory voltado à Internet Nome do servidor: exchcas01.contoso.com	mail.contoso.com	mail.contoso.com autodiscover.contoso.com *.contoso.com	Público	Servidor	O Nome de entidade e a entrada de SAN devem corresponder para dar suporte aos dispositivos de UC externos. O mail.contoso.com como nome de entidade e entrada de SAN é um exemplo de nome usado para se referir ao Outlook Web Access, ao Outlook Anywhere, ao EWS e ao Catálogo de endereços off-line. As únicas exigências são que a entrada deve corresponder ao registro de DNS e que o ExternalURL e outras entradas de serviço possam ser consultados por determinado nome. A entrada de SAN de autodiscover.<domain namespace> é necessária para dar suporte a dispositivos de UC externos.
Servidor de Acesso para Cliente do Exchange Servidor de Acesso para Cliente do site do Active Directory não voltado à Internet Nome do servidor: internalcas01.contoso.net	internalcas01.contoso.com	internalcas01.contoso.com *.contoso.com	Privado	Servidor	O servidor de Acesso para Cliente do site do Active Directory não voltado à Internet se comunica apenas com clientes e servidores internos. O servidor de Acesso para Cliente do site do Active Directory voltado à Internet realiza proxies de comunicação com esse servidor de Acesso para Cliente se a solicitação vem de um usuário ou serviço em consulta a serviços (por exemplo, caixa de correio) e que é hospedado nesse site do Active Directory. Os serviços de EWS e de Catálogo de endereços off-line no site do Active Directory não voltado à Internet são configurados para usar o certificado implantado. Esse certificado pode vir da CA privada interna. O certificado raiz para a CA privada deve ser importado ao armazenamento Certificados raiz confiáveis de terceiros servidor de Acesso para Cliente do site do Active Directory voltado à Internet.

Cenário 3: Unificação de Mensagens (UM) do Exchange/Servidor de Acesso para Cliente do Exchange implantados em servidores diferentes com proxy reverso para publicação

Componente do Microsoft Exchange	Nome de entidade	Entradas de SAN/Ordem	Autoridade de certificação (CA)	Uso avançado de chave (EKU)	Comentários
Unificação de Mensagens (UM) do Exchange Nome do servidor: exchum01.contoso.com	exchum01.contoso.com	A função UM do Exchange não deve conter uma entrada de SAN	Privado	Servidor	O servidor do UM do Exchange se comunica apenas com clientes e servidores internos. Importe um certificado raiz privado e de CA em cada servidor do UM do Exchange. Crie e designe um certificado único para cada servidor UM do Exchange. O Nome de entidade deve corresponder ao nome do servidor. É preciso habilitar a TLS no servidor UM do Exchange antes de designar um certificado à função UM do Exchange. Designe esse certificado para uso no servidor de Acesso para Cliente do Exchange para integração com o Outlook Web Access e o sistema de IM.
Servidor de Acesso para Cliente do Exchange Nome do servidor: exchcas01.contoso.com	exchcas01.contoso.com	exchcas01.contoso.com mail.contoso.com autodiscover.contoso.com *.contoso.com	Privado	Servidor	O Nome de entidade e a entrada de SAN devem corresponder para dar suporte aos dispositivos de UC externos. Importe um certificado raiz privado e de CA em cada servidor de Acesso para Cliente do Exchange. O mail.contoso.com como nome de entidade e entrada de SAN é um exemplo de nome usado para se referir ao Outlook Web Access, ao Outlook Anywhere, ao EWS e ao Catálogo de endereços off-line. As únicas exigências são que a entrada deve corresponder ao registro de DNS e que o ExternalURL e outras entradas de serviço possam ser consultados por determinado nome. A entrada de SAN de descoberta automática é necessária para dar suporte a dispositivos de UC externos. A entrada para o nome da máquina (neste exemplo: exchcas01.contoso.com) deve existir para a integração com o Outlook Web Access e sistema de IM.
Proxy reverso Nome do servidor: rp.contoso.com	mail.contoso.com	mail.contoso.com autodiscover.contoso.com *.contoso.com	Público	Servidor	Uma entrada correspondendo para o nome de entidade também de estar no SAN do certificado. Finalizar a TLS ou a SSL no proxy reverso e depois reestabelecer uma ou outra ao servidor de Cliente para Acesso causará falha nos dispositivos de UC. Um recurso de alguns produtos como o servidor de Internet Security and Acceleration (ISA) da Microsoft, o Microsoft Forefront Threat Management Gateway e outas implementações de terceiros, o término de TLS ou SSL não podem ser usados se você estiver dando suporte a dispositivos de UC. A entrada de SAN para descoberta automática deve existir para dispositivos de UC para funcionar corretamente.
Servidor de Acesso para Cliente do Exchange Servidor de Acesso para Cliente do site do Active Directory não voltado à Internet Nome do servidor: internalcas01.contoso.com	internalcas01.contoso.com	internalcas01.contoso.com *.contoso.com	Privado	Servidor	O servidor de Acesso para Cliente do site do Active Directory não voltado à Internet se comunica apenas com clientes e servidores internos. O servidor de Acesso para Cliente do site do Active Directory voltado à Internet realiza proxies de comunicação com esse servidor de Acesso para Cliente se a solicitação vem de um usuário ou serviço em consulta a serviços (por exemplo, caixa de correio) e que é hospedado nesse site do Active Directory. Os serviços de EWS e de Catálogo de endereços off-line no site do Active Directory não voltado à Internet são configurados para usar o certificado implantado. Esse certificado pode vir da CA privada interna. O certificado raiz para a CA privada deve ser importado ao armazenamento Certificados raiz confiáveis de terceiros servidor de Acesso para Cliente do site do Active Directory voltado à Internet.

Cenário 4: Unificação de Mensagens (UM) do Exchange/Servidor de Acesso para Cliente do Exchange colocados nos mesmos servidores com proxy reverso para publicação

Componente do Microsoft Exchange	Nome de entidade	Entradas de SAN/Ordem	Autoridade de certificação (CA)	Uso avançado de chave (EKU)	Comentários
Unificação de Mensagens (UM) do Exchange Nome do servidor: exchum01.contoso.com	exchum01.contoso.com	A função UM do Exchange não deve conter uma entrada de SAN	Privado	Servidor	O servidor do UM do Exchange se comunica apenas com clientes e servidores internos. Importe um certificado raiz privado e de CA em cada servidor do UM do Exchange. Crie e designe um certificado único para cada servidor UM do Exchange. O Nome de entidade deve corresponder ao nome do servidor. SAN não é necessário. É preciso habilitar a TLS no servidor UM do Exchange antes de designar um certificado à função UM do Exchange.
Servidor de Acesso para Cliente do Exchange Unificação de Mensagens (UM) do Exchange Nome do servidor: exchcas01.contoso.com	mail.contoso.com	exchcas01.contoso.com mail.contoso.com autodiscover.contoso.com *.contoso.com	Privado	Servidor	O Nome de entidade e a entrada de SAN devem corresponder para dar suporte aos dispositivos de UC externos. Importe um certificado raiz privado e de CA em cada servidor de Acesso para Cliente do Exchange. O mail.contoso.com como nome de entidade e entrada de SAN é um exemplo de nome usado para se referir ao Outlook Web Access, ao Outlook Anywhere, ao EWS e ao Catálogo de endereços off-line. As únicas exigências são que a entrada deve corresponder ao registro de DNS e que o ExternalURL e outras entradas de serviço possam ser consultados por determinado nome. A entrada de SAN de descoberta automática é necessária para dar suporte a dispositivos de UC externos. A entrada para o nome da máquina (neste exemplo: exchcas01.contoso.com) deve existir para a integração com o Outlook Web Access e sistema de IM.
Proxy reverso Nome do servidor : rp.contoso.com	mail.contoso.com	mail.contoso.com autodiscover.contoso.com *.contoso.com	Público	Servidor	Uma entrada correspondendo para o nome de entidade também de estar no SAN do certificado. Finalizar a TLS ou a SSL no proxy reverso e depois reestabelecer uma ou outra ao servidor de Cliente para Acesso causará falha nos dispositivos de UC. Um recurso de alguns produtos como o servidor de ISA, o Forefront Threat Management Gateway (TMG) e outas implementações de terceiros, o término de TLS ou SSL não podem ser usados se você estiver dando suporte a dispositivos de UC. A entrada de SAN para descoberta automática deve existir para dispositivos de UC para funcionar corretamente.
Servidor de Acesso para Cliente do Exchange Servidor de Acesso para Cliente do site do Active Directory não voltado à Internet Nome do servidor: internalcas01.contoso.com	internalcas01.contoso.com	internalcas01.contoso.com *.contoso.com	Privado	Servidor	O servidor de Acesso para Cliente do site do Active Directory não voltado à Internet se comunica apenas com clientes e servidores internos. O servidor de Acesso para Cliente do site do Active Directory voltado à Internet realiza proxies de comunicação com esse servidor de Acesso para Cliente se a solicitação vem de um usuário ou serviço em consulta a serviços (por exemplo, caixa de correio) e que é hospedado nesse site do Active Directory. Os serviços de EWS e de Catálogo de endereços off-line no site do Active Directory não voltado à Internet são configurados para usar o certificado implantado. Esse certificado pode vir da CA privada interna. O certificado raiz para a CA privada deve ser importado ao armazenamento Certificados raiz confiáveis de terceiros servidor de Acesso para Cliente do site do Active Directory voltado à Internet.