Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 1 de 10

Noções Básicas Sobre

Certificados Digitais e SSL
Aplica-se a: Exchange Server 2010 SP2

Tópico modificado em: 2010-08-31

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 A integração do 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

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 2 de 10

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 autoassinado permite que alguns protocolos de
clientes usem SSL em suas comunicações. O Exchange ActiveSync e o Outlook Web
App podem estabelecer uma conexão SSL usando um certificado autoassinado. 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.

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 3 de 10

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

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 4 de 10

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

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 5 de 10

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 A integração do 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
1
Exchange 2010, consulte Atualização do acesso para cliente do Exchange 2003 .e
2
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.

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 6 de 10

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\AllowInternal
UntrustedCerts

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
3
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,
3
consulte Noções básicas de proxy e redirecionamento e Gerenciando Servidores de Acesso
4
para Cliente .

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 7 de 10

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:

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 8 de 10

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
Existem muitos serviços no 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 onde 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.

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 9 de 10

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 A integração do 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
20031 e Atualização do acesso para cliente do Exchange 20072.

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
5
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.

Tabela de Ligações
1
http://technet.microsoft.com/pt-br/library/ee332348.aspx
2
http://technet.microsoft.com/pt-br/library/dd351133.aspx
3
http://technet.microsoft.com/pt-br/library/bb310763.aspx
4
http://technet.microsoft.com/pt-br/library/aa997850.aspx
5
http://go.microsoft.com/fwlink/?linkid=3052&kbid=968858

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011
Noções Básicas Sobre Certificados Digitais e SSL: Ajuda do Exchange 2010 Página 10 de 10

Conteúdo da Comunidade

© 2011 Microsoft. Todos os direitos reservados.

http://technet.microsoft.com/pt-br/library/dd351044(d=printer).aspx 22/12/2011