Noções Básicas Sobre Certificados Digitais e SSL

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2016-11-28

O protocolo SSL é um método utilizado para proteger a comunicação entre um cliente e um servidor. Para um servidor de Acesso para Cliente do Microsoft Exchange Server 2010, o SSL é usado para ajudar a proteger a comunicação entre o servidor e os clientes. Clientes incluem dispositivos móveis, computadores dentro da rede da organização e computadores fora da rede da organização. Isso inclui clientes com e sem conexões VPN (rede virtual privada).

Por padrão, ao instalar o Exchange 2010, as comunicações de clientes são criptografadas com SSL quando o Microsoft Office Outlook Web App, o Exchange ActiveSync e o Outlook Anywhere são usados. Por padrão, os protocolos POP3 e IMAP4 não estão configurados para se comunicar por SSL.

O SSL exige que você use certificados digitais. Este tópico resume os diferentes tipos de certificados digitais e as informações sobre como configurar o servidor de Acesso para Cliente para usar esses tipos de certificados digitais.

Sumário

Visão Geral dos Certificados Digitais

Proxy e Certificados Digitais

Práticas Recomendadas para Certificados Digitais

Limitações do Cliente

Visão Geral dos Certificados Digitais

Certificados digitais são arquivos eletrônicos que funcionam como uma senha online para verificar a identidade de um usuário ou computador. Eles são usados para criar o canal criptografado SSL, usado para a comunicações de clientes. Um certificado é uma declaração digital emitida por uma autoridade de certificação (CA), que valida a identidade do portador do certificado e permite que as partes se comuniquem de forma segura, usando criptografia.

Os certificados digitais:

• Autenticam que seus portadores - pessoas, sites e até mesmo recursos de rede, como roteadores - realmente são quem ou o quê dizem ser.

• Protegem dados trocados online contra roubo ou violação.

Os certificados digitais podem ser emitidos por uma CA de terceiros confiável ou uma infraestrutura de chave pública (PKI) do Microsoft Windows usando Serviços de Certificado, ou podem ser autoassinados. Cada tipo de certificado tem vantagens e desvantagens. Cada tipo de certificado digital é inviolável e não pode ser falsificado.

Os certificados podem ser emitidos para vários usos. Entre eles, autenticação de usuário da Web, autenticação de servidor da Web, S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec (Internet Protocol security), protocolo TLS e assinatura de código.

Um certificado contém uma chave pública e a vincula à identidade de uma pessoa, computador ou serviço que contém a chave privada correspondente. As chaves pública e privada são usadas pelo cliente e pelo servidor para criptografar dados antes que sejam transmitidos. Para usuários, computadores e serviços baseados no Windows, a confiança em uma CA é estabelecida quando há uma cópia do certificado raiz no armazenamento de certificados raiz confiável e o certificado contém um caminho de certificação válido. Para que o certificado seja válido, ele não pode ter sido revogado, nem ter expirado.

Tipos de Certificados

Há três tipos principais de certificados digitais: certificados autoassinados, certificados gerados pela infraestrutura de chave pública (PKI) do Windows e certificados de terceiros.

Certificados autoassinados

Ao instalar o Exchange 2010, um certificado autoassinadoinado é configurado automaticamente. Um certificado autoassinado é assinado pelo aplicativo que o criou. O assunto e o nome do certificado são correspondentes. O emissor e o assunto são definidos no certificado. Um certificado auto-assinado permitirá que alguns protocolos de cliente usem SSL para comunicação. O Exchange ActiveSync e o Outlook Web App podem estabelecer uma conexão SSL usando um certificado auto-assinado. O Outlook Anywhere não funciona com certificados autoassinados. Certificados autoassinados devem ser copiados manualmente para o armazenamento de certificados raiz confiável no computador ou dispositivo móvel cliente. Quando um cliente se conecta a um servidor por SSL e o servidor apresenta um certificado autoassinado, o cliente deve verificar se o certificado foi emitido por uma autoridade confiável. O cliente deve confiar explicitamente na autoridade emissora. Se o cliente confirma a confiança, a comunicação SSL pode continuar.

Pequenas organizações com frequência decidem não usar um certificado de terceiros ou não instalar sua própria PKI para emitir seus próprios certificados. Talvez tomem essa decisão porque essas soluções são muito caras, porque os administradores não têm experiência e conhecimento para criar sua própria hierarquia de certificados, ou por ambas as razões. O custo é mínimo e a instalação é simples quando certificados autoassinados são usados. No entanto, é muito mais difícil estabelecer uma infraestrutura para o gerenciamento do ciclo de vida, renovação, gerenciamento de confiança e revogação do certificado quando certificados autoassinados são usados.

Certificados de Infraestrutura de Chave Pública do Windows

O segundo tipo de certificado é um certificado gerado pela infraestrutura de chave pública (PKI) do Windows. Uma PKI é um sistema de certificados digitais, autoridades de certificação e autoridades de registro (RAs) que verifica e autentica a validade de cada parte envolvida em uma transação eletrônica, usando criptografia de chave pública. Ao implementar uma PKI em uma organização que usa o Active Directory, forneça uma infraestrutura para o gerenciamento do ciclo de vida, renovação, gerenciamento de confiança e revogação do certificado. No entanto, há um custo adicional envolvido na implantação de servidores e infraestrutura para criar e gerenciar certificados gerados pela PKI do Windows.

Os Serviços de Certificados são necessários para implantar uma PKI do Windows, e podem ser instalados em Adicionar ou Remover Programas, no Painel de Controle. Você pode instalar os Serviços de Certificados em qualquer servidor no domínio.

Se você obtiver certificados de uma CA com domínio vinculado ao Windows, poderá usá-la para solicitar ou assinar certificados para emitir para seus próprios servidores ou computadores na rede. Isso permite que você use uma PKI semelhante a um fornecedor terceirizado de certificados, mas é mais barato. Esses certificados PKI não podem ser implantados publicamente, ao contrário de outros tipos de certificado. No entanto, quando um CA de PKI assina o certificado do solicitante usando a chave privada, o solicitante é verificado. A chave pública dessa CA é parte do certificado. Um servidor que possui este certificado no armazenamento de certificado raiz confiável pode usar esta chave pública para descriptografar o certificado do solicitante e autenticar o solicitante.

As etapas para implantar um certificado gerado por PKI são parecidas com as etapas necessárias para implantar um certificado autoassinado. Ainda é preciso instalar uma cópia do certificado raiz confiável da PKI no armazenamento de certificado raiz confiável dos computadores ou dispositivos móveis que devem estabelecer uma conexão SSL com o Microsoft Exchange.

Uma PKI do Windows permite que organizações publiquem seus próprios certificados. Clientes podem solicitar e receber certificados de uma PKI do Windows na rede interna. A PKI do Windows pode renovar ou revogar certificados.

Certificados de Terceiros Confiáveis

Certificados comerciais ou de terceiros são aqueles gerados por uma CA comercial ou de terceiros, posteriormente adquiridos para seu uso em servidores de rede. Um problema dos certificados baseados em PKI e autoassinados é que, por não serem automaticamente confiáveis para o computador cliente ou dispositivo móvel, você deve importar o certificado para o armazenamento de certificado raiz confiável em computadores cliente e outros dispositivos. Certificados comerciais ou de terceiros não têm esse problema. A maioria dos certificados de CA comerciais já é confiável, porque o certificado já reside no armazenamento de certificado raiz confiável. Como o emissor é confiável, o certificado também o é. Usar certificados de terceiros simplifica muito a implantação.

Para organizações grandes ou que precisem implantar certificados publicamente, usar um certificado comercial ou de terceiros é a melhor solução, mesmo incidindo um custo associado ao certificado. Certificados comerciais podem não ser a melhor solução para organizações pequenas e médias e talvez você decida usar uma das outras opções de certificado disponíveis.

Voltar ao início

Escolhendo um Tipo de Certificado

Ao escolher que tipo de certificado instalar, vários fatores devem ser levados em consideração. Para ser válido, um certificado deve ser assinado. Ele pode ser autoassinado ou assinado por uma CA. Um certificado autoassinado tem limitações. Por exemplo, nem todos os dispositivos móveis permitem que um usuário instale um certificado digital no armazenamento de certificado raiz confiável. A capacidade de instalar certificados em um dispositivo móvel depende do fabricante e da operadora do serviço do dispositivo. Alguns fabricantes e operadoras de serviços móveis desabilitam o acesso ao armazenamento de certificado raiz confiável. Neste caso, nem um certificado autoassinado, nem um certificado de uma CA de PKI do Windows podem ser instalados no dispositivo móvel.

A maioria dos dispositivos móveis possui vários certificados comerciais de terceiros confiáveis pré-instalados. Para que a experiência do usuário seja ideal, implemente a autenticação baseada em certificado do Exchange ActiveSync, usando dispositivos que estejam executando o Windows Mobile 6.0 ou uma versão posterior, e use um certificado digital de uma CA de terceiros confiável.

Certificados Padrão do Exchange

Por padrão, o Exchange instala um certificado padrão autoassinado, para que toda a comunicação da rede seja criptografada. Criptografar toda a comunicação da rede requer que todos os servidores do Exchange tenham um certificado X.509 que possam utilizar. Você deve substituir esse certificado autoassinado por um que seja automaticamente confiável por seus clientes.

"autoassinado" significa que um certificado foi criado e assinado apenas pelo próprio servidor do Exchange. Como não foi criado e assinado por uma CA confiável, o certificado padrão autoassinado não será confiável a qualquer software, exceto a outros servidores do Exchange na mesma organização. O certificado padrão está habilitado para todos os serviços do Exchange. Ele tem um Nome Alternativo para o Requerente (SAN) que corresponde ao nome do servidor do Exchange em que está instalado. Também tem uma lista de SANs que inclui o nome do servidor e o nome de domínio totalmente qualificado (FQDN) do servidor.

Embora outros servidores do Exchange em sua organização do Exchange confiem neste certificado automaticamente, o mesmo não acontece para clientes como navegadores da Web, clientes Outlook, telefones celulares e outros clientes de email, além de servidores de email externos. Portanto, considere substituir este certificado por um certificado de terceiros confiável em seus servidores do Exchange que têm a função de servidor Acesso para Cliente instalada, e em quaisquer servidores de Transporte de Hub voltados para fora. Se você tem sua própria PKI interna e todos os seus clientes confiam nessa entidade, também pode usar certificados emitidos por você mesmo.

Requisitos de Certificado por Serviço

Certificados são usados por várias razões no Exchange. A maioria dos clientes também usa certificados em mais de um servidor do Exchange. Em geral, quanto menos certificados você tem, mais fácil se torna o gerenciamento de certificados.

IIS

Todos os serviços do Exchange a seguir usam o mesmo certificado em um dado servidor do Exchange: 

• Outlook Web App

• Painel de Controle do Exchange

• Serviços Web do Exchange

• Exchange ActiveSync

• Outlook Anywhere

• Descoberta Automática

• Distribuição do Catálogo de Endereços do Outlook

Como apenas um único certificado pode ser associado a um site, e como todos esses serviços são oferecidos sob um único site por padrão, todos os nomes que os clientes desses serviços usam devem estar no certificado (ou entrar em um nome curinga no certificado).

POP/IMAP

Certificados usados para POP ou IMAP podem ser especificados separadamente do certificado usado para o IIS. No entanto, para simplificar a administração, é recomendável que você inclua o nome do serviço POP ou IMAP em seu certificado IIS e use um único certificado para todos esses serviços.

SMTP

Um certificado separado pode ser usado para cada conector de recebimento configurado em seus servidores de Transporte de Hub ou Transporte de Borda. O certificado deve incluir o nome que os clientes SMTP (ou outros servidores SMTP) usam para alcançar o conector. Para simplificar o gerenciamento de certificados, considere incluir todos os nomes cujo tráfego TLS deve ser suportado em um único certificado.

Federação Live

O certificado usado para a federação com o Windows Live para os cenários de compartilhamento do Exchange podem incluir qualquer nome. Durante o processo de federação, identifique o certificado que você deseja que seu servidor do Exchange use. Este certificado deve ser emitido por uma autoridade de certificação de terceiros confiável pelo Windows Live. Se você obteve seu certificado do Exchange para outros serviços de uma autoridade de certificação de terceiros confiável pelo Windows Live, pode usar um único certificado para esses serviços e também para a federação com o Windows Live.

Unificação de Mensagens

Ao conectar servidores de Unificação de Mensagens do Exchange aos servidores do Microsoft Office Communications Server 2007 R2 ou a gateways SIP de terceiros ou a um equipamento PBX de telefonia (Central Privada de Comutação Telefônica), é possível usar um certificado atribuído automaticamente ou confiável de terceiros para estabelecer sessões protegidas. É possível usar um único certificado em todos os servidores de Unificação de Mensagens enquanto ele possuir os FQDNs de todos os servidores de Unificação de Mensagens em sua lista SAN. Ou você terá que gerar um certificado diferente para cada servidor de Unificação de Mensagens em que o FQDN do servidor de Unificação de Mensagens esteja presente nas listas de nome comum do sujeito (CN) ou SAN. A Unificação de Mensagens do Exchange não é compatível com certificados curinga com o Communications Server 2007 e com o Communications Server 2007 R2.

O Outlook Web App Instant Messaging com o Office Communications Server 2007 R2

O Outlook Web App no Exchange 2010 inclui uma interface de programação que permite a provedores de mensagens instantâneas escreverem suplementos para controlar a presença e funcionalidades de mensagens instantâneas. Existe um suplemento para o Communications Server 2007 R2. Ao usar esse suplemento, você deve usar um certificado para garantir a conexão entre o servidor do Communications Server 2007 R2 e o servidor de Acesso para Cliente do Exchange 2010. O certificado deve ser instalado nos servidores de Acesso para Cliente do Exchange. É possível usar vários certificados ou um único certificado em todos os servidores de Acesso para Clientes do Exchange 2010 enquanto um dos nomes de host no certificado CN ou SAN estiver presente na Lista de Autorização de Host no Communications Server. Esse valor pode ser qualquer nome de host que estiver disponível no certificado, por exemplo, mail.contoso.com. Certificados curinga não são compatíveis para estabelecer conexões seguras ao Communications Server 2007 ou 2007 R2.

Servidores Exchange Herdados

Se as práticas recomendadas para fazer a transição do Microsoft Exchange Server 2003 ou Exchange Server 2007 para o Exchange 2010 forem seguidas, você terá um novo nome de host - legacy.contoso.com para uso durante o período de coexistência, quando haverá caixas de correio na versões herdadas do Exchange e no Exchange 2010. Esse nome de host herdado também deve ser incluído no certificado utilizado. Para obter mais informações sobre como atualizar do Exchange Server 2003 e do Exchange 2007 para o Exchange 2010, consulte Atualização do acesso para cliente do Exchange 2003.e Atualização do acesso para cliente do Exchange 2007.

Voltar ao início

Proxy e Certificados Digitais

Proxying é o método pelo qual um servidor de Acesso para Cliente envia conexões do cliente para outro servidor de Acesso para Cliente. Existem dois cenários onde um servidor de Acesso para Cliente utilizará o proxy para o tráfego para outro servidor de Acesso para Cliente.

1. Servidores de Acesso para cliente em um site do Active Directory voltado para a Internet utilizarão o proxy para o tráfego para servidores de Acesso para Cliente em um site que não seja voltado para a Internet. Isso garante que todo o processamento de solicitações de clientes seja manipulado o mais próximo possível do servidor de Caixa de Correio do cliente.

2. Servidores de Acesso para Cliente para o Exchange 2010 utilizarão conexões de proxy de clientes com caixas de correio no Exchange 2003 e no Exchange 2007. Essas conexões de cliente são intermediadas por proxy para servidores de Acesso para Cliente do Exchange 2007. Isso acontece porque, para muitos serviços do Exchange, o servidor de Acesso para Cliente não pode processar solicitações para servidores de Caixa de Correio que estão executando uma versão mais antiga do Exchange.

Quando servidores de Acesso para Cliente utilizam o proxy para solicitações, o SSL é usado para criptografia, mas não para autenticação. Na maioria dos casos, um certificado autoassinado pode ser usado para o proxying do servidor de Acesso para Cliente. Se sua organização exige regras de segurança extraordinárias, existe uma chave de configuração que você pode definir para exigir certificados confiáveis para o proxying do servidor de Acesso para Cliente. Você pode configurar a chave a seguir, definindo-a como falsa para este cenário:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts

A edição incorreta do Registro pode causar problemas graves que podem exigir a reinstalação do sistema operacional. Talvez não seja possível resolver os problemas resultantes da edição incorreta do Registro. Antes de editar o Registro, faça backup de todos os dados importantes.

Para obter mais informações sobre proxy, consulte Noções básicas de proxy e redirecionamento.

Reverter Proxies e Certificados

A maioria das implantações do Exchange usa proxies reversos para publicar serviços do Exchange na Internet. Exemplos de produtos de Proxy Reverso comuns são Microsoft Internet Security and Acceleration (ISA) Server e Checkpoint. Estes proxies reversos podem ser configurados para encerrar a criptografia SSL, examinar o tráfego internamente no servidor e abrir um novo canal de criptografia SSL a partir do servidor do proxy reverso para os servidores do Exchange atrás deles. Esse processo é conhecido como ponte SSL. Outra forma de configurar os servidores de proxy reverso é deixar que as conexões SSL passem direto para os servidores do Exchange, atrás dos servidores de proxy reverso. Com qualquer um dos modelos de implantação, os clientes na Internet conectam-se ao servidores de proxy reverso usando um nome de host para o acesso ao Exchange, como mail.contoso.com. Então, o servidor de proxy reverso conecta-se ao Exchange usando um nome de host diferente, como o nome de máquina no servidor de Acesso para Cliente do Exchange. Não é preciso incluir o nome de máquina do servidor de Acesso para Cliente do Exchange em seu certificado, porque os servidores de proxy reverso mais comuns conseguem comparar o nome de host original usado pelo cliente com o nome de host interno do servidor de Acesso para Cliente do Exchange.

Balanceamento de Carga e Certificados

Se você tiver mais de um servidor de Acesso para Cliente, considere configurar uma matriz de servidores de Acesso para Cliente. Essa matriz permitirá que todos os clientes conectem-se aos seus servidores de Acesso para Cliente do Exchange através de um único nome de host. Você pode adicionar quantos computadores servidores de Acesso para Cliente quiser a uma matriz de servidores de Acesso para Cliente desde que todos os servidores de Acesso para Cliente estejam localizados no mesmo site do Active Directory. Para obter mais informações sobre balanceamento de carga e matrizes de servidores de Caixa de Correio, consulte Noções básicas de proxy e redirecionamento e Gerenciando Servidores de Acesso para Cliente.

SSL e DNS Dividido

DNS Dividido é uma tecnologia que permite que você configure diferentes endereços IP para o mesmo nome de host, dependendo de onde a solicitação DNS se originou. Isso também é conhecido como DNS de omissão de rotas, DNS no modo divisão ou DNS de redes separadas. O DNS dividido pode ajudá-lo a reduzir o número de nomes de host que devem ser gerenciados para o Exchange, permitindo que seus clientes conectem-se ao Exchange pelo mesmo nome de host, seja da Internet ou na Intranet. O DNS dividido permite que solicitações provenientes da Intranet recebam um endereço IP diferente das solicitações provenientes da Internet.

O DNS dividido geralmente é desnecessário em uma implantação pequena do Exchange, porque os usuários podem acessar o mesmo ponto de extremidade do DNS, estejam eles na Intranet ou na Internet. No entanto, em implantações maiores, essa configuração resultará em uma carga muito alta no servidor de proxy de saída da Internet e em seu servidor de proxy reverso. Para implantações maiores, configure o DNS dividido para que usuários externos acessem mail.contoso.com e usuários internos acessem internal.contoso.com. Usar o DNS dividido para essa configuração garante que seus usuários não precisarão lembrar de usar nomes de host diferentes, dependendo de onde estão localizados.

PowerShell Remoto

A autenticação e a criptografia Kerberos são usadas para acesso ao PowerShell Remoto, a partir do Console de Gerenciamento do Exchange e do Shell de Gerenciamento do Exchange. Portanto, você não precisa configurar seus certificados SSL para uso com o PowerShell Remoto.

Voltar ao início

Práticas Recomendadas para Certificados Digitais

Embora a configuração dos certificados digitais da sua organização variem com base em suas necessidades específicas, informações sobre práticas recomendadas foram incluídas para ajudá-lo a escolher a configuração de certificado digital certa para você.

Práticas Recomendadas: Usar um Certificado de Terceiros Confiável

Para evitar que clientes recebem erros relacionados a certificados não confiáveis, o certificado usado pelo seu servidor do Exchange deve ser emitido por alguém em quem o cliente confie. Embora a maioria dos clientes possa ser configurada para confiar em qualquer certificado ou emissor de certificado, é mais simples usar um certificado de terceiros confiável em seu servidor do Exchange. Isso acontece porque a maioria dos clientes já confia em seus certificados raiz. Há vários emissores de certificados de terceiros que oferecem certificados configurados especificamente para o Exchange. Você pode usar o Console de Gerenciamento do Exchange para gerar solicitações de certificados que funcionam com a maioria dos emissores de certificados.

Como Selecionar uma Autoridade de Certificação

Uma autoridade de certificação é uma empresa que emite e garante a validade dos certificados. Softwares cliente (por exemplo, navegadores como o Microsoft Internet Explorer, ou sistemas operacionais como o Windows ou Mac OS) têm uma lista interna de CAs em que confiam. A lista geralmente pode ser configurada para adicionar ou remover CAs, mas essa configuração é geralmente cansativa. Use os seguintes critérios ao selecionar uma CA para adquirir seus certificados:

• Garanta que o software cliente (sistemas operacionais, navegadores e telefones celulares) que se conectará aos seus servidores do Exchange confia na CA.

• Escolha uma CA que declare o suporte oferecido a "certificados de Comunicações Unificadas" para uso com o servidor do Exchange.

• Certifique-se de que a CA ofereça suporte aos tipos de certificados que você usará. Considere o uso de certificados de Nome Alternativo para o Requerente (SAN). Nem todas as CAs oferecem suporte a certificados SAN, e outras CAs não oferecem suporte a tantos nomes de host quantos você possa precisar.

• Certifique-se de que a licença adquirida para os certificados permite que você coloque o certificado no número de servidores que pretende usar. Algumas CAs só permitem que você coloque um certificado em um servidor.

• Compare os preços dos certificados entre as CAs.

Práticas Recomendadas: Usar Certificados SAN

Dependendo de como os nomes de serviço em sua implantação do Exchange estão configurados, seu servidor do Exchange pode exigir um certificado que represente vários nomes de domínio. Embora um certificado curinga, como um para *.contoso.com, possa resolver este problema, muitos clientes ficam desconfortáveis com as implicações de segurança de manter um certificado que pode ser usado por qualquer subdomínio. Uma alternativa mais segura é listar cada um dos domínios necessários como SANs no certificado. Por padrão, esta abordagem é usada quando as solicitações de certificado são geradas pelo Exchange.

Práticas Recomendadas: Usar o Assistente de Certificado do Exchange para Solicitar Certificados

Há muitos serviços em Exchange que usam certificados. Um erro comum ao solicitar certificados é fazer a solicitação sem incluir o conjunto correto de nomes de serviço. O assistente de solicitação de certificado no Console de Gerenciamento do Exchange o ajudará a incluir a lista correta de nomes na solicitação do certificado. O assistente permite que você especifique com quais serviços o certificado tem que trabalhar e, com base nos serviços selecionados, inclui os nomes que você deve ter no certificado, para que ele possa ser usado com esses serviços. Execute o assistente de certificado quando o conjunto inicial de servidores do Exchange 2010 estiver implantado e os nomes de host para uso com os diferentes serviços para a sua implantação estiverem determinados. Em condições ideais, você só precisará executar o assistente de certificado uma vez para cada site do Active Directory em que o Exchange estiver implantado.

Ao invés de se preocupar em esquecer um nome de host na lista SAN do certificado que você adquiriu, você pode usar uma autoridade de certificado que ofereça, sem custos, um período de cortesia durante o qual você pode devolver um certificado e solicitar o mesmo certificado novo, com alguns nomes de host adicionais.

Práticas Recomendadas: Usar o Mínimo de Nomes de Host Possível

Além de usar o mínimo de certificados possível, você também deve usar o mínimo de nomes de host possível. Essa prática pode economizar dinheiro. Muitos provedores de certificados cobram uma taxa com base no número de nomes de host adicionados ao certificado.

A etapa mais importante para reduzir o número de nomes de host que você deve ter e, portanto, a complexidade do gerenciamento do seu certificado, é não incluir nomes de host de servidor individuais nos nomes alternativos para requerente do certificado.

Os nomes de host que devem ser incluídos em seus certificados do Exchange são os nomes de host usados pelos aplicativos cliente para se conectarem ao Exchange. A seguir, uma lista de nomes de host típicos que seriam exigidos para uma empresa chamada Contoso:

• Mail.contoso.com   Este nome de host cobre a maioria das conexões para o Exchange, incluindo o Microsoft Office Outlook, o Outlook Web App, o Outlook Anywhere, o Catálogo de Endereços Offline, os Serviços Web do Exchange, POP3, IMAP4, SMTP, o Painel de Controle do Exchange e o ActiveSync.

• Autodiscover.contoso.com   Este nome de host é usado por clientes que suportam a Descoberta Automática, incluindo clientes do Microsoft Office Outlook 2007 e versões posteriores, do Exchange ActiveSync, e dos Serviços Web do Exchange.

• Legacy.contoso.com   Este nome de host é exigido em um cenário de coexistência com o Exchange Server 2003 ou o Exchange 2007. Se você tem clientes com caixas de correio em ambas as versões herdadas do Exchange e no Exchange 2010, configurar um nome de host herdado evita que os usuários precisem aprender uma segunda URL durante o processo de atualização. Para obter mais informações sobre atualização e coexistência, consulte Atualização do acesso para cliente do Exchange 2003 e Atualização do acesso para cliente do Exchange 2007.

Noções Básicas de Certificados Curinga

Um certificado curinga é criado para dar suporte a um domínio e vários sub-domínios. Por exemplo, a configuração de um certificado curinga para *.contoso.com resulta em um certificado que funcionará para mail.contoso.com, web.contoso.com e autodiscover.contoso.com.

Voltar ao início

Limitações do Cliente

Vários clientes do Exchange limitam os certificados a que oferecem suporte. Esses clientes e suas limitações estão resumidos abaixo: 

• Outlook no Windows XP ou sistemas operacionais anteriores   O componente RPC sobre HTTP do Windows usado para o Outlook Anywhere exige que o SAN ou nome comum do certificado corresponda ao Nome Principal do Certificado configurado para o Outlook Anywhere. O Outlook 2007 e versões posteriores usam a Descoberta Automática para obter este Nome Principal de Certificado. Para configurar este valor em seu servidor de Acesso para Cliente do Exchange 2010, use o comando Set-OutlookProvider com o parâmetro -CertPrincipalName. Defina este parâmetro para o nome de host externo que os clientes do Outlook para se conectarem ao Outlook Anywhere.

• Versões do Outlook anteriores ao Outlook 2010 não oferecem suporte a certificados SAN para acesso POP3 e IMAP4   Um hotfix está disponível para suporte ao SAN no Outlook 2007 Service Pack 2. O hotfix pode ser encontrado aqui.

• Dispositivos móveis   Alguns dispositivos móveis, incluindo aqueles executando o Windows Mobile 5.0 e alguns dispositivos Palm, não oferecem suporte a certificados curinga.

 © 2010 Microsoft Corporation. Todos os direitos reservados.