Uso de certificados no Exchange 2007 Server

 

Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Tópico modificado em: 2008-05-19

O Microsoft Exchange Server 2007 usa certificados para ajudar a proteger muitos caminhos de comunicação por email. Este tópico foi projetado como uma introdução de ponta a ponta ao uso de certificados no Exchange 2007. Esse tópico explica o seguinte:

• Como os certificados são usados no Exchange 2007.

• Como determinar se você deve comprar um certificado emitido por uma CA (autoridade de certificação) pública de terceiros e quando o certificado auto-assinado padrão é suficiente.

• Como os atributos de certificados são usados pelos componentes do Exchange 2007 e como as propriedades do certificado se relacionam aos campos de extensão X.509 do certificado.

• Confiança e validação de certificados.

• Como criar, importar e habilitar certificados do Exchange 2007.

• Como os componentes do Exchange selecionam certificados do armazenamento do PC.

Cada seção deste tópico contém referências e links para documentação relacionada a certificados para o Exchange 2007.

Reconhecimento   A maior parte deste conteúdo foi adaptada a partir de notas e documentos internos da Microsoft coletados e fornecidos por Stuart Presley, engenheiro de suporte.

Conteúdo

• Componentes do Exchange 2007 que usam certificados para criptografar ou autenticar sessões

• Como determinar quando usar certificados emitidos por CAs públicas e quando usar certificados auto-assinados

• Compreendendo atributos de certificados e como o Exchange 2007 os usa

• Confiança e validação de certificados

• Criando, importando e habilitando certificados

• Seleção de certificado

• Para obter mais informações

Componentes do Exchange 2007 que usam certificados para criptografar ou autenticar sessões

O Exchange 2007 usa certificados X.509 para negociar canais de transporte de comunicação TLS e SSL seguros para protocolos como HTTPS, SMTP, e POP e IMAP.

TLS é o protocolo padrão da IETF (Internet Engineering Task Force) que ajuda a fornecer privacidade e segurança em comunicações entre dois aplicativos que se comunicam por uma rede. O TLS criptografa as comunicações e permite que os clientes autentiquem servidores e, opcionalmente, que os servidores autentiquem clientes. O TLS é uma versão mais segura do protocolo SSL, no qual se baseia. O SSL foi desenvolvido antes pela Netscape. Os dois protocolos têm funções equivalentes. E a maioria das implementações oferece suporte a ambos para compatibilidade com versões mais antigas de clientes que só trabalham com SSL.

A comunicação protegida por TLS pode ser usada para apenas confidencialidade (criptografia) ou para confidencialidade e autenticação ao mesmo tempo. Os certificados X.509 podem ser auto-assinados, também conhecidos como auto-emitidos, em emitidos por uma CA X.509. Uma CA X.509 pode ser uma autoridade pública de certificação de terceiros que emite certificados ou uma PKI (infra-estrutura de chave pública) implantada em sua organização. Exceto se especificado o contrário, este tópico se refere a ambas as soluções como CAs (autoridades de certificação). CAs públicas de terceiros são conhecidas como CAs públicas.

Os componentes do Exchange 2007 a seguir usam certificados para criptografar ou autenticar sessões:

• SMTP   Certificados são usados para criptografia e autenticação de Segurança de Domínio entre organizações parceiras. Os certificados são usados para conexões de confiança direta entre servidores de Transporte de Hub e servidores de Transporte de Borda. Os certificados são usados entre servidores de Transporte de Hub para criptografar a sessão SMTP. No Exchange 2007, confiança direta é a funcionalidade de autenticação para a qual a presença do certificado no serviço de diretório do Active Directory ou no serviço de diretório do ADAM (Active Directory Application Mode) valida o certificado. O Active Directory é considerado um mecanismo de armazenamento confiável. Os certificados também são usados para sessões TLS oportunas entre organizações. Para obter mais informações, consulte Funcionalidade TLS e terminologia relacionada do Exchange 2007.

• Sincronização EdgeSync   Um certificado auto-assinado criado pelo Exchange 2007 é usado para criptografar a sessão de comunicação LDAP entre a instância do ADAM nos servidores de Transporte de Borda e os servidores internos do Active Directory depois que o serviço do Microsoft Exchange EdgeSync replica os dados do Active Directory para a instância do ADAM no servidor de Transporte de Borda. Um certificado auto-assinado é aquele assinado pelo próprio criador. O serviço Microsoft Exchange EdgeSync é o serviço de sincronização de dados que periodicamente replica os dados de configuração do Active Directory para um servidor de Transporte de Borda inscrito. Para obter mais informações, consulte Compreendendo o processo de sincronização EdgeSync.

• POP3 e IMAP4   Os certificados são usados para autenticar e criptografar a sessão entre clientes POP3 e IMAP4 e servidores Exchange. Para obter mais informações, consulte Gerenciando a segurança POP3 e IMAP4.

• Unificação de Mensagens   Os certificados são usados para criptografar a sessão SMTP pra servidores de Transporte de Hub e para o gateway IP da UM (Unificação de Mensagens) e o Microsoft Office Communications Server 2007. Para obter mais informações, consulte Compreendendo a segurança VoIP da Unificação de Mensagens.

• Descoberta Automática   Os certificados são usados para criptografar o caminho HTTP entre o cliente e o servidor de Acesso para Cliente. Para obter mais informações, consultePapel Branco: Exchange 2007 Autodiscover Service.

• Aplicativos de Acesso para Cliente   Os certificados são usados para criptografar o caminho entre o servidor de Acesso para Cliente e diversos clientes HTTP, como o Outlook em Qualquer Lugar, o Microsoft Outlook Web Access e dispositivos com suporte para o Microsoft Exchange ActiveSync. Para obter mais informações, consulte Gerenciando a segurança do acesso para cliente.

Para obter informações mais específicas sobre como cada caminho de dados do Exchange 2007 é criptografado e autenticado, consulte Referência da segurança de caminho de dados..

Voltar ao início

Como determinar quando usar certificados emitidos por CAs públicas e quando usar certificados auto-assinados

O objetivo desta seção é fornecer uma explicação rápida de como o Exchange 2007 usa certificados. Depois de ler esta seção, você deverá saber, com base nos componentes do Exchange que tiver habilitado e nos clientes que deseja suportar, que tipo de certificados deverá obter de uma CA pública. Esta seção também fornece o contexto geral do conteúdo mais técnico que vem a seguir.

É importante compreender que, como o objetivo desta seção é permitir que você determine rapidamente suas necessidades gerais de certificados em relação a CAs públicas, a seção é necessariamente curta. Para ser breve, muitas generalizações sobre certificados e tecnologias relacionadas são criadas para ilustrar o uso de certificados no Exchange 2007. Se você não entender alguns conceitos nessa seção, certifique-se de ler o resto desse tópico e a documentação de referência.

Geralmente, qualquer componente do Exchange 2007 que usa autenticação Kerberos, Direct Trust ou NTLM pode usar um certificado auto-assinado para criptografia. Neste tópico, esses componentes são chamados de componentes internos do Exchange 2007. A palavra interno refere-se ao fato de que os caminhos de dados estão entre os servidores do Exchange 2007 e a rede corporativa definida pelo Active Directory.

Recomendamos que você implemente um certificado emitido por uma CA pública sempre que seus usuários acessem componentes do Exchange que exijam autenticação e criptografia de fora do firewall corporativo. Por exemplo, todos os diversos clientes suportados pela função de servidor Acesso para Cliente, como o Exchange ActiveSync, POP3, IMAP4 e Outlook em Qualquer Lugar, devem ser protegidos por um certificado emitido por uma CA pública. Neste tópico, esses componentes são chamados de componentes externos do Exchange 2007. A palavra externo refere-se ao fato de que os caminhos de dados entre os clientes e o Exchange 2007 atravessam o firewall corporativo e se estendem até a Internet.

Componentes internos usam certificados auto-assinados

Como mencionado anteriormente, muitos componentes do Exchange 2007 usam certificados. Geralmente, todos os caminho de dados internos do Exchange protegidos por certificados não requerem um certificado emitido por uma CA pública.

Todo o tráfego SMTP de de UM interno é protegido por certificados auto-assinados que são instalados quando você executa a Instalação do Exchange 2007 Server. Embora seja recomendável renovar esses certificados anualmente usando o cmdlet New-ExchangeCertificate, você não precisa ter um certificado emitido por uma CA pública para executar os componentes de mensagens internos padrão do Exchange.

O Exchange 2007 dispõe de um conjunto de cmdlets para criar, solicitar e gerenciar certificados TLS. Para obter mais informações sobre esses cmdlets, consulte Cmdlets de certificados mais adiante neste tópico. Por padrão, esses certificados são auto-assinados. Como explicado anteriormente neste tópico, um certificado auto-assinado é aquele assinado pelo próprio criador. No Exchange 2007, o certificado auto-assinado é criado pelo computador que está executando o Microsoft Exchange com a CAPI (Certificate API) subjacente do Windows. Como os certificados são auto-assinados, os certificados resultantes geralmente são menos confiáveis do que aqueles gerados por uma CA. Portanto, é recomendável usar certificados auto-assinados somente para os seguintes cenários internos:

• Sessões SMTP entre servidores de Transporte de Hub: Um certificado é usado somente para criptografia da sessão SMTP. A autenticação é fornecida pelo protocolo Kerberos.

• Sessões SMTP entre servidores de Transporte de Hub e um servidor de Transporte de Borda: Um certificado é usado para criptografia da sessão SMTP e autenticação de confiança direta.

• Sincronização EdgeSync entre servidores de Transporte de Borda e o Active Directory: Um certificado é usado para criptografar a sessão de comunicação LDAP entre a instância do ADAM nos servidores de Transporte de Borda e os servidores internos do Active Directory depois que o serviço do Microsoft Exchange EdgeSync replica os dados do Active Directory para a instância do ADAM no servidor de Transporte de Borda.

• Comunicação da Unificação de Mensagens: Um certificado é utilizado para codificar o tráfego de SIP e RTP entre servidores UM e UM IP gateways, IP/PBXs, e computadores que estão executando o Office Communications Server 2007. O certificado também é utilizado para codificar o tráfego SMTP quando correio de voz ou mensagens de fax são enviados de servidores UM para servidores de Transporte de Hub.

• Um servidor de Acesso para Cliente que é acessado somente por clientes internos.

O acesso de clientes externos ao Exchange requer certificados emitidos por uma CA pública

Componentes internos do Exchange podem confiar em certificados auto-assinados porque os certificados não são usados para autenticação. A autenticação da maioria dos componentes do Enchange é fornecida pelo Kerberos ou NTLM. Na comunicação entre um servidor de Transporte de Borda e um servidor de Transporte de Hub, sempre é usada a autenticação de confiança direta. Ela é fornecida por um certificado e pelo fato de que a chave pública do servidor de Transporte de Borda está armazenada no Active Directory, que é um armazenamento confiável. Do contrário, certificados auto-assinados são usados para fornecer uma chave efêmera para criptografar caminhos de dados entre componentes do Exchange.

Contudo, para acesso de clientes externos da Internet à rede onde o Exchange está hospedados, é necessária a validação tradicional de certificado de confiança. É uma prática recomendada usar um certificado emitido por uma CA pública para validação de confiança. Na verdade, quando a autenticação de certificados é necessária, o uso de um certificado auto-assinado não é uma prática recomendada e é altamente desaconselhável. Recomendamos que você use um certificado de uma CA pública para o seguinte:

• Acesso de clientes POP3 e IMAP4 ao Exchange

• Outlook Web Access

• Outlook em Qualquer Lugar

• Exchange ActiveSync

• Descoberta Automática

• Segurança de domínio

A prática recomendada para todos esses casos é usar uma CA pública que seja confiável por padrão para todos os clientes.

Use o cmdlet New-ExchangeCertificate para gerar uma solicitação de certificado de acordo com as especificações da CA pública de terceiros que emitirá o certificado.

Para obter mais informações, consulte os seguintes tópicos:

• New-ExchangeCertificate

• Criando um certificado ou uma solicitação de certificado de TLS

• Lições aprendidas do Exchange 2007 – gerando um certificado com uma CA de terceiros

  Dica

    O conteúdo de cada site e blog e suas URLs estão sujeitos a alterações sem aviso.

O resto desta seção fornece informações sobre como determinar o tipo de certificado público que você deve obter e se é necessário comprar vários certificados para ajudar a proteger os clientes que sua organização usa para acessar o Exhange 2007.

Determinando o tipo e o número de certificados emitidos por uma CA pública para sua implantação

A seleção do certificado emitido por CA pública adequado para sua organização depende dos seguintes fatores:

• Suporte do cliente para nomes curinga em certificados   Responda: A quais clientes oferecerei suporte? Como mencionado anteriormente, "clientes" nesse contexto se refere a clientes que acessam o Exchange a partir da Internet.

• O namespace de sua organização   Como está configurado o namespace do IIS (Serviços de Informações da Internet) voltado para a Internet?

• Origem do certificado   Onde você obterá o certificado? A CA pública selecionada suporta o uso de caracteres curinga nos campos Assunto ou SAN (Nome de Assunto Alternativo)? Se não, ela suporta o uso de SANs?

As seções a seguir examinam esses fatores mais detalhadamente.

Suporte do cliente para nomes curinga em certificados

Nomes curinga podem ser usados nas extensões Assunto ou SAN dos certificados X.509. Para obter mais informações sobre nomes curinga, consulte "CertificateDomains" em Compreendendo atributos de certificados e como o Exchange 2007 os usa, mais adiante neste tópico.

Depois de determinar quais clientes sua organização deverá suportar, é útil determinar se os clientes oferecem suporte a certificados onde são usados nomes curinga no certificado do servidor ao qual o cliente se conecta.

Se seu cliente suportar o uso de nomes curinga no certificado, o planejamento geral de certificados de sua organização será muito simplificado. Se todos os seus clientes suportarem nomes curinga em certificados e sua organização usar um único nome de domínio, você não precisará considerar o planejamento de namespace na estratégia de implantação de certificados. Ao invés disso, você poderá criar um único certificado que suporte seu namespace com um caractere curinga. Por exemplo, se os clientes que executam o Outlook Web Access usam mail.contoso.com/owa para acessar suas mensagens e clientes POP3 usam pop.contoso.com, um único certificado com um Assunto curinga *.contoso.com suportará ambos os clientes.

Os clientes Microsoft a seguir suportam nomes curinga em certificados:

• Outlook

  Dica

  Quando certificados curiga são implantados em servidores Exchange que estão executando a função de Acesso para Clientes, configurações de Autodiscover requerem configurar para permitir que clientes do Outlook 2007 se conectem com sucesso. Para saber mais sobre esse problema e resolvê-lo, consulte Certificados curinga causam problemas de conectividade no cliente no Outlook em Qualquer Lugar.

• Internet Explorer (Outlook Web Access)

• Servidor de Transporte de Borda do Exchange (Segurança de Domínio)

Se um cliente com suporte em sua organização não suportar nomes curinga no certificado do servidor e você tiver vários namespaces de clientes para os quais precisa oferecer suporte, você deverá

1. Comprar um certificado com vários nomes, como mail.contoso.com, pop.contoso.com e mobile.contoso.com na extensão SAN.

2. Comprar um certificado para cada entidade no namespace ao qual o cliente se conectará.

Planejando o namespace de sua organização

Todos os clientes requerem uma URL ou um FQDN (nome de domínio totalmente qualificado) com os quais se conectarem. Cada caminho ao qual o cliente se conecta deve estar associado a um certificado válido que contenha o nome do host, o nome NetBIOS, o FQDN ou o nome comum do host ao qual o cliente está se conectando. Determinar a lista de nomes a serem incluídos no certificado é o processo de planejamento de namespace.

Geralmente, o planejamento de namespace em organizações grandes com suporte a muitos clientes diferentes e espalhadas em várias regiões com diversos servidores é mais complexo do que o planejamento de namespace pra organizações menores.

Você deve compreender o planejamento de namespace para certificados de modo a saber quais nomes de host devem ser incluídos na extensão SAN do certificado usado para ajudar a proteger as conexões de entrada no Exchange 2007.

Para obter mais informações, consulte Compreendendo o planejamento de namespace do Exchange Server 2007.

Onde conseguir seu certificado

Como mencionado anteriormente, para acesso de clientes externos, recomendamos comprar um certificado de uma CA pública de terceiros.

Ao avaliar autoridades de certificação, considere os seguintes critérios:

• A CA permite nomes curinga no certificado? Se seus clientes suportam nomes curinga no certificado, o método mais simples de implantar clientes seguros é comprar um certificado de uma CA que suporte nomes curinga.

• A CA suporta a extensão SAN? Pode ser interessante usar um certificado com suporte a vários nomes no SAN se as seguintes condições forem verdadeiras:

  • Você oferecer suporte a clientes que não suportem nomes curinga no certificado.

  • Você possui mais de um caminho host aos quais os clientes devem se conectar.

  A Microsoft tem parcerias com CAs públicas para o fornecimento de um certificado de Unificação de Comunicações. Para obter uma lista atualizada das CAs que suportam certificados de Unificação de Comunicações, consulte o artigo 929395 da Base da Dados de Conhecimento Microsoft, Parceiros de certificados de Unificação de Comunicações para o Exchange 2007 e o Communications Server 2007 (página em inglês).

• A CA oferece um nível alto de verificação de autenticidade? Algumas CAs são muito baratas. Outras cobram centenas de dólares por um certificado. Como você depende da integridade desse certificado para autenticar o tráfego de entrada em sua organização, recomendamos que você não escolha uma CA pública apenas pelo preço. Avalie e compare cuidadosamente os serviços oferecidos e a reputação de cada CA antes de decidir.

Voltar ao início

Compreendendo atributos de certificados e como o Exchange 2007 os usa

Compreender os diversos atributos dos certificados ajudará você a entender como eles são usados pelo Exchange. Essa compreensão, por sua vez, ajudará você a planejar suas necessidades de certificados na organização do Exchange. Ajudará também a solucionar solucionar problemas.

Certificados X.509 têm dois tipos de atributos.

• Os campos dos certificados são atributos dentro dos dados assinados do próprio certificado X.509. Esses campos têm sua integridade protegida pela assinatura, e os valores não podem ser alterados sem uma nova assinatura ou re-emissão do certificado.

• As propriedades dos certificados são atributos que são metadados do certificado ou chave privada. Algumas propriedades são intrínsecas ao certificado ou chave privada, como a impressão digital dos certificados. Contudo, muitas propriedades podem ser alteradas sem uma nova assinatura do certificado.

  Por exemplo, o cmdlet Enable-ExchangeCertificate permite que você adicione serviços às propriedades dos certificados depois de sua criação. Você pode habilitar certificados para serem usados por IIS, como o Outlook Web Access ou o Exchange ActiveSync, SMTP como confiança direta ou Segurança de Domínio, IMAP, POP e Unificação de Mensagens. Habilitar um certificado para um serviço em particular atualiza as propriedades do certificado. Para obter mais informações, consulte Enable-ExchangeCertificate.

Você pode exibir esses atributos executando o cmdlet Get-ExchangeCertificate com o argumento |FL em um determinado certificado. Se você estiver executando o Exchange 2007 RTM, deverá executar o cmdlet com o argumento |FL* para exibir todos os dados de atributos.

Alguns campos e propriedades especificados na saída do cmdlet Get-ExchangeCertificate são mapeados para campos de extensão X.509 que podem ser exibidos com o Gerenciador de Certificados no MMC (Console de Gerenciamento Microsoft). Para obter mais informações sobre o Gerenciador de Certificados, consulte Como adicionar o Gerenciador de Certificados ao Console de Gerenciamento Microsoft. Para obter mais informações sobre o cmdlet Get-ExchangeCertificate, consulte Get-ExchangeCertificate.

Campos do certificado

Como já foi explicado, os campos dos certificados são atributos dentro dos dados assinados do próprio certificado X.509. Esta seção explica os campos de certificados usados pelos serviços do Microsoft Exchange e exibidos na saída do cmdlet Get-ExchangeCertificate.

Alguns desses campos também são parâmetros que você pode configurar ao criar um novo certificado ou uma solicitação de certificado com o cmdlet New-ExchangeCertificate. Para obter mais informações sobre o cmdlet New-ExchangeCertificate, consulte New-ExchangeCertificate.

Cada campo de certificado desta seção está listado de acordo com a saída do cmdlet Get-ExchangeCertificate. Cada nome de campo de certificado do Exchange desta seção é mapeado para um nome de extensão de certificado X.509.

Issuer

Este campo contém o nome comum que identifica o emissor do certificado. Certificados auto-assinados criados pelo Exchange durante a instalação ou pelo cmdlet New-ExchangeCertificate exibem cn=hostname, onde hostname é o nome do servidor local.

Certificados emitidos por CAs normalmente exibem o nome comum completo da CA no campo Issuer.

O nome de extensão de certificado X.509 também é Issuer.

O campo Issuer não tem um parâmetro correspondente que você possa configurar no cmdlet New-ExchangeCertificate. O campo Issuer é especificado pela entidade que emite o certificado.

Subject

Esse campo identifica o assunto do certificado. Subject é uma cadeia de caracteres X.500 que normalmente representa um único nome usado para acessar o serviço que usa o certificado. Quando um certificado é criado pelo cmdlet New-ExchangeCertificate, se o assunto não for expressamente especificado, Subject será o primeiro valor listado no parâmetro DomainName quando você executar o cmdletNew-ExchangeCertificate. Os campos X.500 a seguir podem estar presentes:

• C = País

• ST = Estado

• L = Local

• O = Organização

• OU = Unidade Organizacional

• CN = Nome Comum

Alguns desses campos são necessários para gerar solicitações de certificados para CAs de terceiros. Para obter uma explicação mais detalhada sobre o campo Subject, consulte Criando um certificado ou uma solicitação de certificado de TLS.

Se você estiver executando o Microsoft ISA (Internet Security and Acceleration) Server 2006 na frente do Exchange para fazer ponte, leia o post no blog, Certificados com várias entradas SAN podem quebrar a publicação do ISA Server na Web, para obter mais informações sobre nomes de assunto e o comportamento do ISA Server.

Quando o Exchange gera um certificado auto-assinado sem nenhum argumento de usuário, ele cria um certificado que contém o nome de assunto CN=hostname.

O nome de extensão de certificado X.509 também é Subject.

O campo Subject é configurado especificando o parâmetro SubjectName no cmdlet New-ExchangeCertificate.

CertificateDomains

O campo CertificateDomains identifica todos os nomes de domínios DNS associados a um certificado. Nomes de domínio DNS podem estar tanto no atributo do nome comum (cn=) de Subject ou na extensão SAN de um certificado. A saída do cmdlet Get-ExchangeCertificate exibe a união do domínio no campo Subject e de todos os domínios encontrados no SAN.

Os valores encontrados no campo CertificateDomains podem incluir o nome do host ou FQDN usados para acessar o servidor. Para usar um certificado, o FQDN usado por um cliente para se conectar ao servidor deve aparecer no campo CertificateDomains do certificado.

Por exemplo, se um cliente estiver se conectando a um servidor usando POP3 com mail.fourthcofee.com como nome do servidor, o certificado associado às configurações POP3 poderá conter mail.fourthcofee.com no campo CertificateDomains.

Você também poderá encontrar certificados com nomes curinga, como *.fourthcofee.com. Esse é um domínio aceitável. Contudo, lembre-se de que alguns clientes e dispositivos móveis herdados não suportam nomes curinga em um certificado, e podem não suportar o uso de domínios curinga.

Para obter uma explicação detalhada sobre como usar SANs e nomes curinga em certificados, consulte Criando um certificado ou uma solicitação de certificado de TLS. Além disso, o Blog da Equipe do Exchange, Lições aprendidas do Exchange 2007 - gerando um certificado com uma CA de terceiros (página em inglês), contém conselhos práticos sobre como criar uma solicitação de certificado com vários SANs.

O nome da extensão do certificado X.509 é Subject Alternative Name mas, como já foi observado, a saída do cmdlet Get-ExchangeCertificate também adiciona o valor contido na extensão de certificado Subject à lista de nomes do campo CertificateDomains.

Você pode configurar o campo CertificateDomains especificando os parâmetros DomainName e Subject do cmdlet New-ExchangeCertificate.

NotBefore e NotAfter

Os valores dos campos NotBefore e NotAfter representam o intervalo de datas durante o qual o certificado é válido. Se a data atual for posterior à data NotAfter, o certificado será considerado expirado. O Microsoft Exchange ainda pode usar certificados expirados, mas os clientes gerarão avisos e o servidor registrará os eventos apropriados no log de eventos.

O nome de extensão de certificado X.509 que é mapeado para o valor NotBefore é Valid from. O nome de extensão de certificado X.509 que é mapeado para o valor NotAfter é Valid to.

Os campos NotBefore e NotAfter não têm parâmetros correspondentes que você possa definir no cmdlet New-ExchangeCertificate. Esses campos são definidor pela entidade que emite o certificado. Certificados auto-assinados gerados pela instalação do Exchange ou pelo cmdlet New-ExchangeCertificate são válidos por um ano.

CertificateRequest

Este valor está presente apenas em certificados que ainda estão em estado de solicitação. Solicitações de certificados não são Certificados X.509 válidos e não serão usados pelo Exchange.

O campo CertificateRequest é habilitado especificando a opção de parâmetro GenerateRequest do cmdlet New-ExchangeCertificate.

Propriedades do Certificado

Como explicado anteriormente, as propriedades dos certificados são atributos que são metadados do certificado ou chave privada. Algumas propriedades são intrínsecas ao certificado ou chave privada, como a impressão digital dos certificados, mas muitas propriedades podem ser alteradas sem uma nova assinatura do certificado.

Com exceção da propriedade Thumbprint, nenhuma propriedade de certificados do Exchange correspondem a uma extensão de certificado X.509.

Esta seção explica as propriedades dos certificados.

IsSelfSigned

A propriedade IsSelfSigned indica se um certificado é auto-assinado. Um certificado auto-assinado normalmente é um certificado raiz. Esse certificado não possui outros certificados na cadeia de certificados. O certificado auto-assinado do Exchange normalmente se refere aos seguintes tipos de certificados:

• Um certificado gerado quando o Exchange é instalado em um servidor onde não há um certificado qualificativo presente.

• Um certificado resultante da execução do cmdlet New-ExchangeCertificate.

Quando as funções de servidor de Transporte de Hub, Transporte de Borda, Unificação de Mensagens ou Acesso para Cliente são instaladas, a Instalação do Exchange gera um certificado auto-assinado. Se existir um certificado válido no armazenamento de certificados Pessoal do computador host, o certificado existente será usado e o certificado auto-assinado gerado pela Instalação do Exchange não será usado. Os valores válidos são True ou False.

RootCAType

A propriedade RootCAType identifica o tipo de CA que emitiu o certificado. Se o parâmetro IsSelfSigned estiver configurado como True, o valor da propriedade RootCAType deverá ser None. Do contrário, o certificado poderá causar resultados inesperados no processo de seleção de certificados. Outros valores possíveis são:

• Registry   Uma CA interna de PKI privada instalada manualmente no armazenamento de certificados.

• ThirdParty   Uma CA raiz pública de terceiros.

• GroupPolicy   Uma CA interna de PKI privada instalada com a Diretiva de Grupo.

• Enterprise   Uma CA interna de PKI privada instalada com o Active Directory.

• Unknown   O Exchange não consegue determinar o tipo de que certificado está instalado.

Compreender como o certificado da CA raiz foi instalado no computador pode ajudar a diagnosticar diretivas de confiança inconsistentes. Essas inconsistências podem fazer com que os certificados sejam validados em alguns servidores mas não em outros.

Por exemplo, um valor Registry indica que alguém instalou manualmente o certificado em um servidor. Isso pode causar inconsistências se o certificado não tiver sido instalado em outros servidores da organização. Recomendamos distribuir certificados para todos os computadores com a Diretiva de Grupo ou o Active Directory.

Serviços

A propriedade Services identifica os serviços com os quais esse certificado pode ser usado. Os valores válidos são SMTP, POP, IMAP, UM, e IIS.

Você pode definir o valor do campo Services especificando o parâmetro Services no cmdlet Enable-ExchangeCertificate. Para obter mais informações, consulte Enable-ExchangeCertificate.

Status

A propriedade Status indica se o certificado é válido. O campo Status é muito útil a solução de problemas de certificados. Se o valor de Status para um determinado certificado não for Valid, o certificado não será usado pelo servidor Exchange para nenhum serviço. Os valores da propriedade Status podem ser os seguintes:

• Desconhecido   Esse status geralmente indica que o status do certificado não pode ser verificado porque a CRL (lista de revogação de certificado) não está disponível ou o servidor não consegue se conectar a ela. Verifique se o computador consegue se conectar à Autoridade de Revogação de Certificados. Para obter mais informações, consulte Como definir configurações de proxy para WinHTTP.

• Válido   O certificado está funcionando corretamente.

• Revogado   A CRL indicou que o certificado foi revogado. É necessário gerar um novo certificado.

• DateInvalid   Esse status indica que a hora do sistema está incorreta, o certificado expirou, ou a hora do sistema que assinou o arquivo está incorreta. Verifique se as seguintes condições são verdadeiras:

  • O relógio local do computador está certo.

  • O certificado não expirou.

  • O relógio do sistema de envio está certo.

  Se o certificado tiver expirado, você deverá gerar um novo certificado.

• Não confiável   Esse status indica que o certificado não é auto-assinado. Contudo, ele é assinado por uma CA que não é confiável para o computador local. Você deve adicionar o certificado da CA ao armazenamento de Autoridades de Certificação Raiz Confiáveis do computador. Para obter mais informações sobre como adicionar certificados manualmente ao armazenamento local de certificados, consulte o arquivo da Ajuda relativo ao Gerenciador de Certificados do MMC.

• Inválido   Algum outro problema invalidou este certificado, como um certificado não confiável, inválido ou revogado em algum ponto do caminho do certificado.

Para obter mais informações sobre solução de problemas, consulte os seguintes tópicos:

• Como corrigir erros de validação de certificado

• Como testar configurações de PKI e proxy

• Como definir configurações de proxy para WinHTTP

HasPrivateKey

A propriedade HasPrivateKey indica se o certificado instalado tem uma chave privada. Isso é muito importante, porque o serviço de Transporte do Microsoft Exchange, o serviço POP3 do Microsoft Exchange e o serviço IMAP4 do Microsoft Exchange não usarão um certificado que não tenha uma chave privada.

Thumbprint

A propriedade Thumbprint pe uma cadeia de caracteres exclusiva que identifica o certificado. Se o mesmo certificado for instalado em vários servidores Exchange, você poderá identificá-los por sua impressão digital. Normalmente, o mesmo certificado é instalado em vários servidores Exchange quando vários servidores de Transporte de Borda estão aceitando mensagens com o mesmo FQDN, como mail.fourthcoffee.com. É muito mais econômico instalar o mesmo certificado em vários servidores do que solicitar um novo certificado para cada servidor. Contudo, o certificado deve ter uma chave privada que possa ser exportada.

A propriedade Thumbprint é usada para especificar um certificado para os seguintes cmdlets:

• Get-ExchangeCertificate

• Remove-ExchangeCertificate

• Export-ExchangeCertificate

• Enable-ExchangeCertificate

O nome de extensão de certificado X.509 que é mapeado para a propriedade Thumbprint também é Thumbprint.

Voltar ao início

Confiança e validação de certificados

Para usar um certificado para autenticação, ele deve ser validado e confiável.

Para validar um determinado certificado X.509, é necessário confiar na CA raiz que emitiu o certificado. Uma CA raiz é a CA mais confiável. Ela fica no alto de uma CA. A autoridade de certificação raiz possui um certificado auto-assinado. Quando você executa um aplicativo que depende da autenticação de certificado, cada certificado deve possuir uma cadeia que termine em um certificado no contêiner da raiz confiável do computador local. O contêiner de raiz confiável contém certificados de CAs raiz.

Um certificado é encadeado a uma CA por outro certificado. Esse certificado também pode ser emitido por uma CA, e portanto teria que ser encadeado a ela. Esse encadeamento de certificados também é conhecido como o caminho de certificação. Todos os certificados do caminho de certificação devem ser válidos para que o certificado seja válido. Além disso, o certificado no topo da cadeia deve ser uma CA raiz confiável.

Existem dois tipos de CAs de raiz confiável que podem ser usados para implementar aplicativos que dependem de autenticação de certificados: CAs raiz públicas de terceiros e CAs raiz particulares.

Autoridades de Certificação raiz públicas de terceiros

O Windows, o Windows Mobile e vários sistemas operacionais de terceiros contém um conjunto de CAs raiz internas públicas de terceiros. Se confiar nos certificados emitidos por essas CAs raiz públicas de terceiros, você poderá confirmar os certificados emitidos por elas.

A confiança será automática se as condições a seguir forem verdadeiras:

• Sua organização usa a instalação padrão do Windows,

• O software cliente e os dispositivos móveis usados na organização também confiam nas CAs raiz públicas de terceiros internas,

Nesse caso, a configuração adicional de confiabilidade não será necessária.

Autoridades de certificação raiz confiáveis particulares

Uma CA raiz confiável particular é uma CA raiz implantada por uma PKI particular ou interna. Por exemplo, quando sua organização tiver implantado uma PKI interna com seu próprio certificado raiz, você precisará fazer configurações de confiança adicionais.

Geralmente, não é uma prática recomendada usar certificados emitidos por uma PKI privada para aplicativos de clientes que suportem conexões externas com sua organização.

Quando são usadas CAs raiz privadas, você deve atualizar o armazenamento de certificados Raiz Confiável do Windows em todos os dispositivos, clientes e sistemas operacionais do Windows onde for necessária a autenticação de certificados.

A confiança pode ser configurada de duas maneiras: confiança direta na raiz e certificação cruzada.

Confiança direta na raiz

Para conceder confiabilidade a um certificado emitido por uma CA raiz particular, adicione manualmente esse certificado raiz ao armazenamento de certificados Raiz Confiável no computador que estiver executando o Windows. Em alguns casos, você também poderá adicionar um certificado raiz ao armazenamento raiz confiável de clientes móveis. Para obter mais informações sobre como adicionar certificados manualmente ao armazenamento local de certificados em um computador que esteja executando o Windows, consulte o arquivo da Ajuda relativo ao Gerenciador de Certificados do MMC. Para obter mais informações sobre como instalar certificados em dispositivos com o Windows Mobile, consulte Como instalar certificados raiz em um dispositivo com o Windows Mobile (página em inglês).

Certificação cruzada

A certificação cruzada ocorre quando uma CA assina um certificado gerado por outra CA. A certificação cruzada é usada para criar confiança entre PKIs. Se você possuir sua própria PKI, em vez de usar confiança direta manual para uma CA raiz ou outra PKI privada, você poderá criar uma certificação cruzada da outra CA em sua CA raiz. Nesse caso, a confiança será estabelecida porque a certificação cruzada estará interligada à sua CA raiz confiável.

Configurando acesso à lista de certificados revogados

Quando um serviço específico, como o serviço de Transporte do Microsoft Exchange no cenário SMTP/TLS ou o ISS no cenário HTTPS, recupera um certificado, o serviço valida a cadeia de certificados e o certificado. A validação do certificado é um processo em que muitos de seus atributos são confirmados. A maioria desses atributos pode ser confirmada no computador local pelo aplicativo que solicita o certificado. Por exemplo, o uso pretendido do certificado, as datas de expiração do certificado e outros atributos semelhantes podem ser verificados fora do contexto de uma PKI. No entanto, a confirmação de que o certificado não foi revogado deverá ser validada pela CA que o emitiu. Assim, a maior parte das CAs disponibiliza uma lista de certificados revogados (CRL) para que o público possa validar o status de revogação.

Para autenticar com êxito com certificados, os serviços que estão autenticando o cliente devem ter CRLs à disposição para as CAs que você usa. Se a verificação de revogação falhar, o serviço de autenticação falhará.

Seus servidores de autenticação devem conseguir acessar CRLs de CAs externas.

Todas as CAs públicas possuem CRLs disponíveis ao público, que podem ser contatadas pelos servidores de sua organização. Em alguns casos, as CRLs de PKIs internas privadas só ficam disponíveis com o protocolo LDAP. Na maioria dos casos, com CAs públicas, as CRLs são publicadas via HTTP. Verifique se as portas de saída apropriadas e os proxies estão configurados para permitir que seus servidores e clientes entrem em contato com a CRL. É possível determinar qual protocolo um determinado ponto de distribuição de CRL aceita, abrindo um certificado no MMC e exibindo o campo Pontos de Distribuição de CRL.

Em alguns casos, pode ser necessário disponibilizar a CRL da CA que emite seus certificados. Por exemplo, se você estiver implantando a Segurança de Domínio, é necessário compreender que, mesmo quando o servidor de Transporte de Borda recupera um certificado de sua própria organização, ele valida a cadeia de certificados para validar o certificado. Portanto, a CRL de sua CA deve estar disponível para seus servidores de Transporte de Borda. Além disso, todos os parceiros com os quais você troca emails de domínio seguro devem poder acessar a CRL da CA que emite seus certificados.

Configurando definições de proxy para WinHTTP

Servidores Exchange 2007 dependem dos serviços Windows HTTP (WinHTTP) subjacentes para gerenciar todo o tráfego HTTP e HTTPS. Por exemplo, os servidores de Transporte de Hub e de Transporte de Borda podem usar HTTP para acessar Atualizações de Filtro Anti-spam Padrão do Exchange 2007 e o serviço de atualização anti-spam do Microsoft Forefront Security para Exchange Server Todas as funções de servidor do Exchange usam WinHTTP para habilitar a validação de CRL.

Para obter mais informações, consulte Como definir configurações de proxy para WinHTTP.

Testando a configuração de proxy e PKI

Para verificar a configuração de proxy e PKI de um servidor do Exchange específico, use Certutil.exe para verificar a cadeia de certificados do certificado do servidor. Certutil.exe é uma ferramenta de linha de comando que é instalada como parte dos Serviços de Certificado nos sistemas operacionais Windows Server. Para obter mais informações, consulte Como testar configurações de PKI e proxy.

Voltar ao início

Criando, importando e habilitando certificados

Existem diversas maneiras de obter um certificado instalado e operacional no Exchange 2007. A escolha dos métodos depende de suas necessidades. O Exchange 2007 gera um conjunto de certificados auto-assinados para permitir a proteção da configuração padrão. Ele deve ser renovado de tempos em tempos para ajudar a garantir a segurança do sistema. O Exchange não gera automaticamente solicitações de assinatura para autoridades de certificação. Se você desejar criar um novo certificado auto-assinado ou uma solicitação de certificado para uma autoridade de certificação, ambos os métodos usam o mesmo cmdlet.

Essa seção fornece um panorama sobre as operações que você pode realizar em certificados utilizados pelo Exchange 2007. Leia essa seção se não for familiarizado com os cmdlets ExchangeCertificate. São fornecidos exemplos e procedimentos para aplicativos específicos mais adiante neste documento, usando POP3 como exemplo. Esta seção também contém links para documentos para aplicativos específicos.

Cmdlets de certificados

Em versões anteriores do Exchange Server, todo o gerenciamento de certificados era feito através do IIS e do Gerenciador de Certificados no MMC. No Exchange 2007, a maioria das tarefas de gerenciamento de certificados relacionadas ao Exchange é executada pelos seguintes cmdlets ExchangeCertificate cmdlets com o Shell de Gerenciamento do Exchange:

• New-ExchangeCertificate   Este cmdlet gera certificados auto-assinados e solicitações de certificados para autoridades de certificação.

• Import-ExchangeCertificate   Este cmdlet importa certificados que foram exportador anteriormente e importa arquivos de certificados gerados por CAs.

• Export-ExchangeCertificate   O cmdlet exporta certificados para backup ou para serem usados em vários servidores.

• Enable-ExchangeCertificate   Este cmdlet habilita serviços específicos em um certificado.

• Get-ExchangeCertificate   Esse cmdlet exibe os atributos de um certificado.

• Remove-ExchangeCertificate   Este cmdlet remove certificados do Exchange Server e do armazenamento de certificados local.

Para obter mais informações sobre como criar solicitações de certificados para autoridades de certificação, consulte Criando um certificado ou uma solicitação de certificado de TLS.

As seções a seguir oferecem exemplos curtos para ilustrar como você pode usar os cmdlets ExchangeCertificate para executar tarefas comuns de certificados. Para obter mais informações e exemplos, consulta a Ajuda do cmdlet ExchangeCertificate em Cmdlets globais.

Gerando certificados auto-assinados

Para gerar um certificado auto-assinado para ser usado pelo serviço SMTP para um servidor com o nome de host Server1 e domínio fourthcoffee.com, execute o seguinte comando:

New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

Clonando certificados auto-assinados

Se um certificado auto-assinado existente precisar ser renovado, você poderá cloná-lo executando o seguinte comando:

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

O marcador thumbprint é a impressão digital do certificado que será renovado. Os serviços do novo certificado também podem ser especificados no comando a seguir:

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

Você pode então habilitar esse certificado, executando o seguinte comando:

Enable-ExchangeCertificate <thumbprint>

Criando solicitações de certificados e instalando certificados confiáveis

Instalar um certificado público de terceiros pe um processo mais complexo. Você deve gerar uma solicitação de certificado, importar o certificado emitido e todos os certificados necessários da CA e depois habilitar o certificado emitido para seu uso ou usos pretendidos.

Esta seção fornece um exemplo de como habilitar o serviço POP3 para uso de certificados. Neste exemplo, os clientes se conectam ao serviço POP3 conectando-se ao FQDN, popserver.fourthcoffee.com.

Solicitação de certificado

Como o certificado resultante vem de uma CA pública de terceiros, você precisa primeiro gerar uma solicitação de certificado, executando o seguinte comando:

New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

Se a solicitação de certificado for gerada corretamente, um arquivo de solicitação de certificado (.cer ou .der) será criado na raiz da unidade do sistema e o Shell de Gerenciamento do Exchange exibirá uma Impressão Digital da solicitação.

No comando anterior, o parâmetro PrivateKeyExportable é definido como $True para que esse certificado possa ser exportado juntamente com a chave privada para ser usado em vários servidores Exchange que podem ter que ser acessados com o mesmo FQDN. Por exemplo, vários servidores de Acesso para Cliente podem ter suas cargas equilibradas pra suportar conexões POP3.

O comando anterior também especifica o parâmetro Subjectname como um nome X.500. A maioria das CAs de terceiros exigem que você especifique um nome X.500 válido para o nome do Assunto do certificado. No mínimo, a maioria das CAs requerem que a organização descrita no campo organizationName (o=) possua o nome de domínio que aparece em commonName (cn=) no servidor da Web.

Depois de concluída a solicitação, o arquivo de solicitação pode ser enviado para um fornecedor de certificados para se obter um certificado.

Importando um certificado

Depois que um certificado é retornado pela CA, você deve importá-lo para o servidor Exchange. Para importar corretamente um certificado para o qual foi gerada uma solicitação com o cmdlet New-ExchangeCertificate, execute o seguinte comando:

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

Se o certificado for importado com êxito, esse comando retornará uma impressão digital do certificado, que você poderá usar para habilitar serviços específicos.

Habilitando um certificado

Habilitar um certificado permite que você especifique quais serviços podem usar um determinado certificado. O comando a seguir habilita o certificado emitido para o serviço POP3:

Enable-ExchangeCertificate <thumprint> -Services:"POP"

Você pode importar e habilitar um certificado ao mesmo tempo, executando o seguinte comando:

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

Validando a instalação do certificado

Para confirmar se todas as etapas necessárias foram concluídas e se o certificado está instalado e funcionando, execute o seguinte comando:

Get- ExchangeCertificate <thumbprint> | fl *

A saída desse comando retorna dados semelhantes a estes:

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=3rdPartyCAExample.com
NotAfter           : 8/7/2008 10:04:02 AM
NotBefore          : 8/7/2007 10:04:02 AM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 83FAE8B2398F2A9E44485CBA85D548DF
Services           : POP
Status             : Valid
Subject            : C=us,o=contoso corp, CN=fourthcoffee.com 
Thumbprint         : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

Inspecione o resultado deste comando para verificar se as informações a seguir são verdadeiras:

• Os nomes de domínio que você espera estão listados no campo CertificateDomains.

• A propriedade HasPrivateKey está configurada como True.

• A propriedade RootCAType está definida corretamente. Para obter mais informações sobre a propriedade RootCAType, consulte Propriedades do Certificado neste documento.

• Os serviços necessários estão habilitados para o certificado.

• O Status está definido como Valid.

Serviços de Certificado

Serviços como POP, IMAP, IIS e SMTP podem se habilitados em um certificado. Os serviços não são campos no próprio certificado. Eles são propriedades de metadados dos certificados. Portanto, você pode alterá-los sem invalidar o certificado.

Quando os serviços são habilitados, ocorrem alterações de configuração em outros componentes, como a Metabase IIS, o sistema de arquivos ou nas configurações IMAP4 ou POP3. Esta seção descreve as alterações de configuração que ocorrem quando você habilita um determinado serviço executando o cmdlet Enable-ExchangeCertificate.

POP e IMAP

Quando POP e IMAP são acrescentados a um certificado como serviços adicionais, o atributo x509CertificateName do objeto POPSettings ou IMAPSettings é atualizado, incluindo o domínio no assunto do certificado.

Por exemplo, para verificar se o objeto POPSettings foi atualizado, execute o seguinte comando:

Get-POPSettings | fl *

IIS

Quando o IIS é habilitado, o site padrão do IIS é atualizado para usar esse certificado específico.

Você pode habilitar um certificado par ao IIS usando o cmdlet Enable-ExchangeCertificate somente para o site padrão do IIS. Se você estiver hospedando sites do Outlook Web Access ou da Descoberta Automática que não sejam o site padrão do IIS, deverá usar o Gerenciador do IIS para associar um certificado específico a esses sites.

SMTP

Quando o serviço SMTP é habilitado em um certificado, a conta do Serviço de Rede recebe acesso de Leitura ao arquivo apropriado de chave privada no diretório Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys. Essa ação fornece a permissão necessária para que o serviço de Transporte do Microsoft Exchange acesse e use a chave privada para descriptografar mensagens protegidas por TLS.

Serviço de Unificação de Mensagens do Microsoft Exchange

Quando o serviço de Unificação de Mensagens do Microsoft Exchange é habilitado em um certificado, a propriedade do certificado é atualizada de modo a incluir a Unificação de Mensagens. O certificado é usado quando as condições a seguir são verdadeiras:

• A função de servidor Unificação de Mensagens está instalada no computador.

• O certificado tem o FQDN físico do computador no campo CertificateDomains do certificado.

Voltar ao início

Seleção de certificado

A seleção do certificado é um processo que os componentes do Exchange executam para determinar qual certificado deve ser usado para uma conexão de entrada. SMTP STARTTLS, POP3, e IMAP4 executam um processo de seleção similar para determinar qual certificado usar para uma determinada sessão. Esse processo é bastante determinista. Contudo, ele pode ser confuso, principalmente quando há mais de um certificado instalado no computador.

Esta seção descreve o processo de seleção de certificado para SMTP STARTTLS, SMTP X-AnonymousTLS, POP3, e IMAP4. Para obter mais informações sobre a seleção de certificados específica para tipos de transporte, consulte Seleção de certificado TLS SMTP.

SMTP STARTTLS

STARTTLS é o verbo SMTP que inicia uma sessão TLS segura. STARTTLS só é anunciado pelo Exchange se houver um certificado válido no computador que executa o Exchange.

Para anunciar ou usar STARTTLS, o Exchange seleciona um certificado com base no FQDN e um valor correspondente no campo CertificateDomains de um certificado. O FQDN se baseia nas seguintes informações:

• STARTTLS de saída   O certificado é selecionado com base no valor do FQDN em um Conector de Envio.

• STARTTLS de entrada   O certificado é selecionado com base no valor do FQDN em um Conector de Recebimento.

  Dica

  Para STARTTLS de saída e STARTTLS de entrada, se o FQDN do conector não for especificado, o FQDN físico do servidor Exchange será usado para a correspondência.

Depois que o FQDN é determinado, o Exchange pesquisa todos os certificados válidos no armazenamento de certificados Pessoal no computador host. Um certificado será válido para uso com TLS se ele cumprir todos os seguintes requisitos:

• O campo Enhanced Key Usage contém o identificador de objeto da Autenticação de Servidor (também chamado de OID) ou é nulo.

• A extensão de certificado de PKI lista uma chave RSA de no mínimo 1024 bits.

• O certificado valida a cadeia de certificados até uma raiz confiável, ou o certificado é auto-assinado.

• O certificado e a cadeia de certificados passam no teste de revogação.

• A chave privada está presente e disponível.

• A chave privada não está armazenada em um dispositivo móvel.

• A chave privada não está protegida por senha.

Se for encontrado mais de um certificado válido, o Exchange selecionará o certificado com base nos seguintes critérios:

• O valor do campo NotBefore   O Exchange seleciona o certificado válido mais recente.

• Certificados emitidos por uma CA confiável vs. certificados auto-assinados   O Exchange prefere certificados emitidos por uma CA confiável do que certificado auto-assinados.

Na maioria dos casos, o Exchange seleciona um certificado emitido por uma CA confiável ao invés de um certificado auto-assinado, independentemente da idade do certificado. Se não for encontrado um certificado válido, STARTTLS não será anunciado.

SMTP X-AnonymousTLS

X-AnonymousTLS é usado para ajudar a proteger a comunicação entre dois servidores de Transporte de Hub e entre servidores de Transporte de Hub e servidores de Transporte de Borda. No Exchange 2007 SP1, o processo de seleção de certificados foi simplificado de forma que, se nenhum certificado for encontrado, é gerada uma chave temporária de criptografia para a sessão.

O Exchange procura um certificado de transporte interno. Se não for encontrado um certificado de transporte interno válido, o Exchange procura um certificado de CA válido.

Portanto, para a comunicação entre Hubs onde o protocolo Kerberos é usado para autenticação, a ausência de um certificado de transporte interno válido não causa falha na sessão SMTP. A sessão SMTP é criptografada com a chave de criptografia temporária. Nesse caso, é registrado um evento e você deverá criar um novo certificado de transporte interno, executando o cmdlet New-ExchangeCertificate sem argumentos no computador que gerou o evento.

Para comunicações de Hub para Borda, onde o servidor de Transporte de Borda estiver inscrito na organização, se um certificado de transporte interno válido não for encontrado, a sessão falhará e será registrado um erro. Nesse caso, você deverá executar o cmdlet New-ExchangeCertificate sem argumentos no computador que gerou o evento e, em seguida, executar o serviço Microsoft Exchange ActiveSync novamente.

POP3 e IMAP4

Assim como no processo de seleção de certificados para SMTP STARTTLS, no processo para POP3 e IMAP4 o Exchange seleciona um FQDN e encontra um certificado com base em um valor correspondente no campo CertificateDomains. O FQDN é escolhido com base no atributo X509CertificateName das configurações do serviço POP3 ou IMAP4. Você pode exibir o atributo X509CertificateName executando o cmdlet Get-POPSettings ou o cmdlet Get-IMAPSettings. Para obter mais informações, consulte Get-POPSettings e Get-IMAPSettings.

O processo de seleção para POP3 e IMAP4 no Exchange 2007 SP1 é igual ao processo para SMTP STARTTLS.

Unificação de Mensagens

Se o serviço de Unificação de Mensagens do Microsoft Exchange for iniciado em modo de segurança, ele consultará o armazenamento de certificados local Pessoal para localizar um certificado válido a ser usado para TLS para habilitar criptografia. O serviço de Unificação de Mensagens do Microsoft Exchange procura primeiramente um certificado válido emitido por uma PKI privada ou CA pública. Se não for encontrado um certificado adequado, ele procurará um certificado auto-assinado. Se nenhum certificado auto-assinado, público ou de PKI for encontrado, o serviço de Unificação de Mensagens do Microsoft Exchange criará um certificado auto-assinado para usar ao iniciar em modo Seguro. Se o servidor da UM estiver iniciando em modo inseguro, não será necessário nenhum certificado.

Todos os detalhes do certificado usado para iniciar em modo de segurança serão registrados, sempre que o certificado for usado ou se o certificado for alterado. Alguns detalhes registrados no log incluem o seguinte:

• Nome do emissor

• Número de série

• Impressão digital

A impressão digital é o hash SHA1 (Secure Hash Algorithm). Ele pode ser usado para identificar exclusivamente o certificado usado. Você pode exportar o certificado usado pelo serviço de Unificação de Mensagens do Microsoft Exchange para iniciar no modo seguro a partir do armazenamento de certificados local e importar esse certificado para os gateways IP e PBXs IP da Unificação de Mensagens de sua rede para o armazenamento de certificados confiáveis.

Depois que um certificado adequado é encontrado e usado, o serviço de Unificação de Mensagens do Microsoft Exchange registrará um evento um mês antes da expiração do certificado em uso. Se você não realizar nenhuma alteração no certificado durante esse tempo, o serviço de Unificação de Mensagens do Microsoft Exchange registrará um evento por dia até o certificado expirar e um evento por dia após a expiração.

Ao procurar um certificado para o uso da TLS mútua para estabelecer um canal criptografado, o servidor de Unificação de Mensagens examinará o armazenamento de certificados raiz confiáveis. Se houver vários certificados válidos e de diferentes emissores, o servidor de Unificação de Mensagens escolherá o certificado válido com mais tempo até a expiração. Se houver vários certificados, o servidor de Unificação de Mensagens escolherá os certificados com base no emissor e na data de expiração. O servidor de Unificação de Mensagens procurará um certificado válido nessa ordem.

1. Certificado público ou de PKI com período de expiração mais distante.

2. Certificado comercial ou de PKI com período de expiração mais próximo.

3. Certificado auto-assinado com data de expiração mais distante.

4. Certificado auto-assinado com data de expiração mais próxima.

Voltar ao início

Para obter mais informações

A documentação a seguir foi citada neste tópico:

• Certificados com várias entradas SAN podem quebrar a publicação do ISA Server na Web

• Criando um certificado ou uma solicitação de certificado de TLS

• Criando um certificado ou uma solicitação de certificado de TLS

• Referência da segurança de caminho de dados.

• Enable-ExchangeCertificate

• Lições aprendidas do Exchange 2007 – gerando um certificado com uma CA de terceiros

• Export-ExchangeCertificate

• Get-ExchangeCertificate

• Get-IMAPSettings

• Get-POPSettings

• Como adicionar o Gerenciador de Certificados ao Console de Gerenciamento Microsoft

• Como definir configurações de proxy para WinHTTP

• Como testar configurações de PKI e proxy

• Import-ExchangeCertificate

• Lições aprendidas: Gerando um certificado com um CA de terceiro (em inglês)

• Gerenciando a segurança do acesso para cliente

• Gerenciando a segurança POP3 e IMAP4

• New-ExchangeCertificate

• Remove-ExchangeCertificate

• Seleção de certificado TLS SMTP

• Funcionalidade TLS e terminologia relacionada do Exchange 2007

• Compreendendo o processo de sincronização EdgeSync

• Compreendendo o planejamento de namespace do Exchange Server 2007

• Compreendendo a segurança VoIP da Unificação de Mensagens

• Parceiros de certificação da unificação de comunicações do Exchange 2007 e do Communications Server 2007

• Informe Oficial: Serviço de Descoberta Automática do Exchange 2007

Voltar ao início