Como habilitar PKI no servidor de Transporte de Borda para segurança de domínio
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Tópico modificado em: 2007-08-28
A segurança de domínio depende do protocolo TLS para autenticação. O êxito na autenticação mútua baseada em TLS depende de uma cadeia de certificação X.509 confiável e validada para os certificados TLS usados para a segurança de domínio.
Portanto, antes de implantar a segurança de domínio com êxito, configure o servidor de Transporte de Borda e a infra-estrutura de chave pública (PKI) X.509 para acomodar a validação e confiabilidade do certificado.
Importante
Está além do escopo deste tópico apresentar uma explicação detalhada das tecnologias e conceitos de criptografia e certificação. Antes de implantar uma solução de segurança que use criptografia e certificados X.509, recomendamos que você compreenda os conceitos básicos de confiança, autenticação, criptografia e troca de chaves particulares e públicas no que diz respeito à criptografia. Para obter mais informações, consulte as referências listadas no final deste tópico.
Configurando autoridades de certificação raiz
Para validar um determinado certificado X.509, é necessário confiar na autoridade de certificação raiz (CA) que emitiu o certificado. A CA raiz é a CA mais confiável e se encontra no topo das CAs. 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 autoridades de certificação raiz.
Para enviar emails de um domínio seguro com êxito, você deverá validar o certificado X.509 do servidor de recebimento. Da mesma forma, quando alguém envia um email de um domínio seguro para sua organização, o servidor de envio deverá validar seu certificado.
Existem dois tipos de CAs de raiz confiável que podem ser usados para implementar a segurança de domínio: CAs raiz internas de terceiros e CAs raiz particulares.
Autoridades de certificação raiz de terceiros
O Microsoft Windows inclui um conjunto de CAs raiz internas de terceiros. Se confiar nos certificados emitidos por essas CAs raiz de terceiros, você poderá confirmar os certificados emitidos por elas. Se sua organização e as organizações parceiras estiverem usando a instalação padrão do Windows e confiarem nas CAs raiz internas de terceiros, a confiança será automática. 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 ou a organização com a qual você troca emails de domínio seguro tiver implantado uma PKI interna com seu próprio certificado raiz, você precisará fazer configurações de confiança adicionais.
Quando são usadas CAs raiz particulares, você deve atualizar o armazenamento do certificado raiz confiável do Windows no servidor de Transporte de Borda para que a segurança de domínio funcione corretamente.
A confiança pode ser configurada de duas maneiras: confiança direta na raiz e certificação cruzada. É necessário compreender que sempre que o serviço de transporte seleciona um certificado, ele o valida antes de usá-lo. Portanto, se estiver utilizando uma CA raiz particular para emitir certificados, você deverá incluí-la no armazenamento de certificados raiz confiáveis de cada servidor de Transporte de Borda que envia ou recebe emails de domínios seguros.
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áveis no computador do servidor de Transporte de Borda. Para obter mais informações sobre como adicionar manualmente certificados ao armazenamento local, consulte o arquivo da Ajuda relativo ao snap-in do Gerenciador de Certificados do Console de Gerenciamento do Microsoft (MMC).
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. No contexto de segurança de domínio, se você possuir sua própria PKI, em vez de usar confiança direta manual para uma autoridade raiz de um parceiro com uma PKI interna, você poderá criar uma certificação cruzada para a autoridade de certificação do parceiro sob sua própria autoridade raiz. Nesse caso, a confiança será estabelecida porque a certificação cruzada estará interligada à sua raiz confiável.
É necessário compreender que, se possuir uma PKI interna e estiver usando uma certificação cruzada, você deverá atualizar manualmente o armazenamento de certificados raiz em cada servidor de Transporte de Borda que receber emails de domínios seguros para que cada um desses servidores possa validar os certificados quando receberem emails de parceiros cuja confiabilidade foi estabelecida por meio de certificação cruzada.
Para obter mais informações sobre como adicionar manualmente certificados ao armazenamento local, consulte o arquivo da Ajuda relativo ao snap-in do Gerenciador de Certificados do MMC.
Configurando acesso à lista de certificados revogados
Sempre que o serviço de transporte recupera um certificado, ele valida o certificado e a cadeia de certificados. 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 usar a segurança de domínio com êxito, é necessário disponibilizar as CRLs das autoridades de certificação usadas por você ou por seus parceiros para os servidores de Transporte de Borda que enviam e recebem emails de domínios seguros. Se a verificação de revogação falhar, o servidor de recebimento do Exchange emitirá uma rejeição de protocolo temporária da mensagem. Pode ocorrer uma falha temporária na revogação. Por exemplo, o servidor Web usado para a publicação da CRL pode falhar. Ou ainda, problemas genéricos de conectividade de rede entre o servidor de Transporte de Borda e o ponto de distribuição da CRL podem causar falhas na verificação de revogação. Portanto, as falhas de revogação temporárias só causam atrasos temporários na entrega de emails, pois o servidor de envio tentará novamente mais tarde. Porém, a validação da CRL é necessária para a transmissão bem-sucedida de emails de domínio seguro.
Habilite as seguintes situações:
Os servidores de Transporte de Borda devem ser capazes de acessar as CRLs de CAs externas Cada parceiro com o qual você troca emails de domínio seguro deve possuir CRLs disponíveis ao público que o servidor de Transporte de Borda de sua organização possa contatar. Em alguns casos, as CRLs 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 o servidor de Transporte de Borda entre 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.
Você deve disponibilizar ao público a CRL da CA que emite seus certificados É 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
Os servidores de transporte do Exchange 2007 baseiam-se nos serviços Microsoft Windows HTTP (WinHTTP) subjacentes para gerenciar todo o tráfego HTTP e HTTPS. 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 Microsoft Exchange 2007 e o serviço de atualização anti-spam do Microsoft Forefront Security para Exchange Server e para validação de CRL.
Para obter mais informações, consulte Como definir configurações de proxy para WinHTTP (página em inglês).
Testando a configuração de proxy e PKI
Para verificar a configuração de proxy e PKI de um servidor de Transporte de Borda específico, use Certutil.exe para verificar a cadeia do certificado do servidor de Transporte de Borda. Certutil.exe é uma ferramenta de linha de comando que é instalada como parte dos Serviços de Certificado nos sistemas operacionais Windows Server 2003. Para obter mais informações, consulte Como testar configurações de PKI e proxy (página em inglês).
Para obter mais informações
Para mais informações sobre as autoridades de certificação que operam atualmente nos sites específicos do Exchange, consulte o artigo 929395 da Base de Dados de Conhecimento da Microsoft, Parceiros de Certificação da Unificação de Comunicações para o Exchange 2007 e para o Communications Server 2007 (página em inglês).
Para obter mais informações sobre tecnologias e conceitos de criptografia e certificado, consulte as publicações a seguir:
Housley, Russ e Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. Nova York: John Wiley & Son, Inc., 2001.
Adams, Carlisle e Steve Lloyd. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2ª edição. Nova York: John Wiley & Son, Inc., 1996.