Certificados digitais e SSL

Aplica-se a: Exchange Server 2013

A SSL (Secure Sockets Layer) é um método para proteger as comunicações entre um cliente e um servidor. Para Exchange Server 2013, o SSL é usado para ajudar a proteger as comunicações entre o servidor e os clientes. Entre os clientes estão incluídos celulares, computadores dentro da rede da organização e computadores fora da rede da organização.

Por padrão, quando você instala o Exchange 2013, as comunicações do cliente são criptografadas usando o SSL quando você usa Outlook Web App, Exchange ActiveSync e Outlook Anywhere.

O SSL exige que você utilize certificados digitais. Este tópico resume os diferentes tipos de certificados digitais e informações sobre como configurar o Exchange 2013 para usar esses tipos de certificados digitais.

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 comunicações de cliente. Um certificado é uma instrução digital emitida por uma autoridade de certificação (AC) que atesta a identidade do titular do certificado e permite que as partes se comuniquem de maneira segura usando criptografia.

Os certificados digitais fazem o seguinte:

• Eles autenticam que seus titulares (pessoas, sites e até mesmo recursos de rede, como roteadores) são realmente quem ou o que eles afirmam ser.

• Eles protegem os dados que são trocados online contra roubo ou adulteração.

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

Os certificados podem ser emitidos para vários usos. Esses usos incluem autenticação de usuário web, autenticação de servidor Web, S/MIME (Extensões de Internet Seguro/Multiuso), IPsec (Segurança de Protocolo de Internet), TLS (Segurança de Camada de Transporte) 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úblicas e privadas são usadas pelo cliente e pelo servidor para criptografar os dados antes de serem transmitidos. Para usuários, computadores e serviços baseados no Windows, a confiança em uma AC é estabelecida quando há uma cópia do certificado raiz no repositório de certificado raiz confiável e o certificado contém um caminho de certificação válido. Para que o certificado seja válido, o certificado não deve ter sido revogado e o período de validade não deve ter expirado.

Tipos de certificados

Há três tipos primários de certificados digitais: certificados autoassinados, certificados gerados por PKI do Windows e certificados de terceiros.

Certificados autoassinados

Quando você instala o Exchange 2013, um certificado autoassinado é configurado automaticamente nos servidores da caixa de correio. Um certificado autoassinado é assinado pelo aplicativo que o criou. O assunto e o nome do certificado correspondem. O emissor e o assunto são definidos no certificado. Esse certificado autoassinado é usado para criptografar as comunicações entre o servidor de Acesso ao Cliente e o servidor da caixa de correio. O servidor de Acesso ao Cliente confia automaticamente no certificado autoassinado no servidor da caixa de correio, portanto, nenhum certificado de terceiros é necessário no servidor da caixa de correio. Quando você instala o Exchange 2013, um certificado autoassinado também é criado no servidor de Acesso ao Cliente. Esse certificado autoassinado permitirá que alguns protocolos de cliente usem o SSL para 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 funcionará com um certificado autoassinado no servidor de Acesso ao Cliente. Certificados autoassinados devem ser copiados manualmente para o repositório de certificados raiz confiável no computador cliente ou dispositivo móvel. Quando um cliente se conecta a um servidor por SSL e o servidor apresenta um certificado autoassinado, o cliente será solicitado a verificar se o certificado foi emitido por uma autoridade confiável. O cliente deve confiar explicitamente na autoridade emissora. Se o cliente confirmar a confiança, as comunicações SSL poderão continuar.

Com frequência, as pequenas organizações decidem não usar um certificado de terceiros ou não instalar seu próprio PKI para emitir seus próprios certificados. Eles podem tomar essa decisão porque essas soluções são muito caras, porque seus administradores não têm experiência e conhecimento para criar sua própria hierarquia de certificados ou por ambos os motivos. O custo é mínimo e a configuração é simples quando você usa certificados autoassinados. No entanto, é muito mais difícil estabelecer uma infraestrutura para gerenciamento do ciclo de vida do certificado, renovação, gerenciamento de confiança e revogação quando você usa certificados autoassinados.

Certificados de infraestrutura de chave pública do Windows

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

Os Serviços de Certificado são necessários para implantar um PKI do Windows e podem ser instalados por meio de adicionar ou remover programas em Painel de Controle. Você pode instalar os Serviços de Certificado em qualquer servidor do domínio.

Se você obter certificados de uma AC do Windows ingressada no domínio, poderá usar a AC para solicitar ou assinar certificados para emitir para seus próprios servidores ou computadores em sua 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, como outros tipos de certificados podem ser. No entanto, quando uma AC 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 possuir este certificado no armazenamento de certificado raiz confiável poderá usar esta chave pública para descriptografar o certificado do solicitante e autenticar o solicitante.

As etapas para implantar um certificado gerado por PKI se assemelham às necessárias para implantar um certificado autoassinado. Você ainda deve instalar uma cópia do certificado raiz confiável do PKI para o repositório de certificados raiz confiável dos computadores ou dispositivos móveis que deseja estabelecer uma conexão SSL com o Microsoft Exchange.

Um PKI do Windows permite que as organizações publiquem seus próprios certificados. Os clientes podem solicitar e receber certificados de um PKI do Windows na rede interna. O PKI do Windows pode renovar ou revogar certificados.

Certificados de terceiros confiáveis

Certificados comerciais ou de terceiros são certificados gerados por uma AC comercial ou de terceiros e comprados para você usar em seus servidores de rede. Um problema com certificados autoassinados e baseados em PKI é que, como o certificado não é confiável automaticamente pelo computador cliente ou dispositivo móvel, você deve importar o certificado para o repositório de certificados raiz confiável em computadores e dispositivos cliente. Certificados comerciais ou de terceiros não têm esse problema. A maioria dos certificados de AC comerciais já é confiável, porque o certificado já reside no repositório de certificado raiz confiável. Como o emissor é confiável, o certificado também é confiável. O uso de certificados de terceiros simplifica muito a implantação.

Para organizações ou organizações maiores que devem implantar certificados publicamente, a melhor solução é usar um certificado comercial ou de terceiros, embora haja um custo associado ao certificado. Os certificados comerciais podem não ser a melhor solução para organizações de pequeno e médio porte e você pode decidir usar uma das outras opções de certificado disponíveis.

Escolhendo um tipo de certificado

Quando você escolhe o tipo de certificado a ser instalado, há várias coisas a serem consideradas. Um certificado deve ser assinado para ser válido. Ele pode ser autoassinado ou assinado por uma AC. Um certificado autoassinado tem limitações. Por exemplo, nem todos os dispositivos móveis permitem que um usuário instale um certificado digital no repositório de certificados raiz confiável. A capacidade de instalar certificados em um dispositivo móvel depende do fabricante de dispositivos móveis e do provedor de serviços móveis. Alguns fabricantes e provedores de serviços móveis desabilitam o acesso ao repositório de certificados raiz confiável. Nesse caso, nem um certificado autoassinado nem um certificado de uma CA PKI do Windows podem ser instalados no dispositivo móvel.

Certificados padrão do Exchange

Por padrão, o Exchange instala um certificado autoassinado no servidor de Acesso ao Cliente e no servidor da caixa de correio para que toda a comunicação de rede seja criptografada. Criptografar toda a comunicação de rede requer que cada servidor do Exchange tenha um certificado X.509 que possa usar. Você deve substituir esse certificado autoassinado no servidor de Acesso ao Cliente 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 ele não foi criado e assinado por uma AC geralmente confiável, o certificado autoassinado padrão não será confiável por nenhum software, exceto outros servidores do Exchange na mesma organização. O certificado padrão está habilitado para todos os serviços do Exchange. Ele tem um SAN (nome alternativo de assunto) que corresponde ao nome do servidor do Exchange no qual ele está instalado. Ele também tem uma lista de SANs que incluem o nome do servidor e o FQDN (nome de domínio totalmente qualificado) do servidor.

Embora outros servidores do Exchange em sua organização do Exchange confiem neste certificado automaticamente, clientes como navegadores da Web, clientes do Outlook, telefones celulares e outros clientes de email, além de servidores de email externos, não confiarão automaticamente nele. Portanto, considere substituir esse certificado por um certificado confiável de terceiros em seus servidores do Exchange Client Access. Se você tiver seu próprio PKI interno e todos os seus clientes confiarem nessa entidade, você também poderá usar certificados que você mesmo emitir.

Requisitos de certificado por serviço

Os certificados são usados para várias coisas no Exchange. A maioria dos clientes também usa certificados em mais de um servidor do Exchange. Em geral, quanto menos certificados você tiver, mais fácil será o gerenciamento de certificados.

IIS

Todos os seguintes serviços do Exchange usam o mesmo certificado em um determinado servidor de Acesso ao Cliente do Exchange:

• Microsoft Outlook Web App

• Centro de administração do Exchange (EAC)

• Serviços de Web do Exchange

• Exchange ActiveSync

• Outlook em Qualquer Lugar

• Descoberta automática

• Distribuição do Outlook Address Book

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

POP/IMAP

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

SMTP

Um certificado separado pode ser usado para cada conector de recebimento que você configurar. O certificado deve incluir o nome que os clientes SMTP (ou outros servidores SMTP) usam para alcançar esse conector. Para simplificar o gerenciamento de certificados, considere incluir todos os nomes para os quais você precisa dar suporte ao tráfego TLS em um único certificado.

Certificados digitais e proxy

Proxying é o método pelo qual um servidor envia conexões de cliente para outro servidor. No caso do Exchange 2013, isso acontece quando o servidor do Client Access proxies uma solicitação de cliente de entrada para o servidor mailbox que contém a cópia ativa da caixa de correio do cliente.

Quando solicitações de proxy de servidores de Acesso ao Cliente, o SSL é usado para criptografia, mas não para autenticação. O certificado autoassinado no servidor da Caixa de Correio criptografa o tráfego entre o servidor de Acesso ao Cliente e o servidor da caixa de correio.

Proxies e certificados reversos

Muitas implantações do Exchange usam proxies reversos para publicar serviços do Exchange na Internet. Proxies reversos podem ser configurados para encerrar a criptografia SSL, examinar o tráfego na limpeza no servidor e, em seguida, abrir um novo canal de criptografia SSL dos servidores proxy reverso para os servidores do Exchange atrás deles. Isso é conhecido como ponte SSL. Outra maneira de configurar os servidores proxy reverso é permitir que as conexões SSL passem diretamente para os servidores do Exchange por trás dos servidores proxy reverso. Com qualquer modelo de implantação, os clientes na Internet se conectam ao servidor proxy reverso usando um nome de host para acesso ao Exchange, como mail.contoso.com. Em seguida, o servidor proxy reverso se conecta ao Exchange usando um nome de host diferente, como o nome do computador do servidor do Exchange Client Access. Você não precisa incluir o nome do computador do servidor de Acesso ao Cliente do Exchange no certificado porque os servidores proxy reverso mais comuns são capazes de corresponder o nome do host original usado pelo cliente ao nome do host interno do servidor de Acesso ao Cliente do Exchange.

SSL e DNS dividido

O DNS dividido é uma tecnologia que permite configurar endereços IP diferentes para o mesmo nome do host, dependendo de onde veio a solicitação DNS de origem. Isso também é conhecido como DNS de omissão de rotas, DNS do modo divisão ou DNS de dupla personalidade. O DNS dividido pode ajudá-lo a reduzir o número de nomes do host que você deve gerenciar para o Exchange, permitindo que os clientes se conectem ao Exchange usando o mesmo nome do host, independente de ser uma conexão a partir da Internet ou da Intranet. O DNS dividido permite que as solicitações originadas da intranet recebam um endereço IP diferente das solicitações originadas da Internet.

A divisão de DNS geralmente é desnecessária em uma pequena implantação do Exchange porque os usuários podem acessar o mesmo ponto de extremidade DNS, seja da intranet ou da Internet. No entanto, com implantações maiores, essa configuração resultará em uma carga muito alta no servidor proxy da Internet de saída e no servidor proxy reverso. Para implantações maiores, configure DNS dividido para que, por exemplo, usuários externos acessem mail.contoso.com e usuários internos acessam internal.contoso.com. O uso de DNS dividido para essa configuração garante que seus usuários não precisem se lembrar de usar nomes de host diferentes, dependendo de onde estão localizados.

Windows PowerShell Remoto

A autenticação Kerberos e a criptografia Kerberos são usadas para acesso remoto Windows PowerShell, tanto do Centro de administração do Exchange (EAC) quanto do Shell de Gerenciamento do Exchange. Portanto, você não precisará configurar seus certificados SSL para uso com Windows PowerShell remotas.

Práticas recomendadas de 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ática recomendada: usar um certificado confiável de terceiros

Para impedir que os clientes recebam erros em relação a certificados não confiáveis, o certificado usado pelo servidor exchange deve ser emitido por alguém em quem o cliente confia. Embora a maioria dos clientes possa ser configurada para confiar em qualquer emissor de certificado ou certificado, é mais simples usar um certificado confiável de terceiros no servidor exchange. Isso ocorre 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 EAC para gerar solicitações de certificado que funcionam com a maioria dos emissores de certificado.

Como selecionar uma autoridade de certificação

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

• Verifique se a AC é confiável pelo software cliente (sistemas operacionais, navegadores e telefones celulares) que se conectarão aos servidores do Exchange.

• Escolha uma AC que diga que dá suporte a "certificados de comunicação unificada" para uso com o servidor exchange.

• Verifique se a AC dá suporte aos tipos de certificados que você usará. Considere usar certificados SAN (nome alternativo do assunto). Nem todos os CAs dão suporte a certificados SAN e outros CAs não dão suporte a tantos nomes de host quanto você precisar.

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

• Compare os preços do certificado entre CAs.

Prática recomendada: usar certificados SAN

Dependendo de como você configurar os nomes de serviço na implantação do Exchange, o servidor do Exchange pode exigir um certificado que possa representar vários nomes de domínio. Embora um certificado curinga, como um para *.contoso.com, possa resolver esse problema, muitos clientes estão desconfortáveis com as implicações de segurança da manutenção de um certificado que pode ser usado para qualquer subdomínio. Uma alternativa mais segura é listar cada um dos domínios necessários como SANs no certificado. Por padrão, essa abordagem é usada quando as solicitações de certificado são geradas pelo Exchange.

Prática recomendada: use o assistente de certificado do Exchange para solicitar certificados

Há 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 certificado no centro de administração do Exchange ajudará você a incluir a lista correta de nomes na solicitação de certificado. O assistente permite especificar com quais serviços o certificado precisa 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 você implantou seu conjunto inicial de servidores do Exchange 2013 e determinou quais nomes de host usar para os diferentes serviços para sua implantação. O ideal é que você só precise executar o assistente de certificado uma vez para cada site do Active Directory em que implantar o Exchange.

Em vez de se preocupar em esquecer um nome de host na lista san do certificado que você compra, você pode usar uma autoridade de certificação que oferece, sem custo, um período de carência durante o qual você pode retornar um certificado e solicitar o mesmo novo certificado com alguns nomes de host adicionais.

Prática recomendada: usar o menor número possível de nomes de host

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

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

Os nomes de host que você deve incluir em seus certificados do Exchange são os nomes de host usados pelos aplicativos cliente para se conectar ao Exchange. Veja a seguir uma lista de nomes de host típicos que seriam necessários para uma empresa chamada Contoso:

• Mail.contoso.com: esse nome de host abrange a maioria das conexões com o Exchange, incluindo Microsoft Outlook, Outlook Web App, Outlook Anywhere, o Catálogo de Endereços Offline, Exchange Web Services, POP3, IMAP4, SMTP, Exchange Painel de Controle e ActiveSync.

• Autodiscover.contoso.com: esse nome de host é usado por clientes que dão suporte a Autodiscover, incluindo o Microsoft Office Outlook 2007 e versões posteriores, Exchange ActiveSync e clientes do Exchange Web Services.

• Legacy.contoso.com: esse nome de host é necessário em um cenário de coexistência com o Exchange 2007 e o Exchange 2013. Se você tiver clientes com caixas de correio no Exchange 2007 e no Exchange 2013, configurar um nome de host herdado impede que seus usuários tenham que aprender uma segunda URL durante o processo de atualização.

Entendendo certificados curinga

Um certificado curinga foi projetado para dar suporte a um domínio e vários subdomínios. Por exemplo, configurar um certificado curinga para *.contoso.com resulta em um certificado que funcionará para mail.contoso.com, web.contoso.com e autodiscover.contoso.com.