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

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

Tópico modificado em: 2011-11-04

Este tópico explica como criar certificados TLS X.509 ou uma solicitação de certificado, usando os cmdlets ExchangeCertificate no Shell de Gerenciamento do Exchange.

Em termos criptográficos, o certificado e as chaves privadas relacionadas que são geradas pelo cmdlet New-ExchangeCertificate são chaves do TLS. O cmdlet New-ExchangeCertificate permite especificar metadados sobre o certificado, de modo que serviços diferentes possam usar o mesmo certificado e chave privada. Antes de criar certificados ou solicitações de certificado de serviços do Exchange que usam o TLS, é preciso compreender os metadados usados pelos certificados de serviços SSL e TLS. Esses metadados são denominados "campos" no certificado resultante.

Para exibir os campos de certificados de um determinado computador, use o cmdlet Get-ExchangeCertificate no Shell de Gerenciamento do Exchange. Como alternativa, use o snap-in Gerenciador de Certificados do MMC (Console de Gerenciamento Microsoft). Para obter mais informações sobre como usar o snap-in Gerenciador de Certificados, consulte Como adicionar o Gerenciador de Certificados ao Console de Gerenciamento Microsoft.

Compreendendo os campos usados por certificados de serviços TLS

Se estiver usando o cmdlet New-ExchangeCertificate para gerar uma solicitação de certificado de terceiros ou de outra autoridade de certificação (CA) de infra-estrutura de chave pública (PKI), certifique-se de validar os campos e o formato do certificado exigidos pela CA.

Esta seção explica os campos mais importantes do certificado e fornece algumas práticas recomendadas para gerar certificados e solicitações de certificado.

Nome do Assunto

O Nome do Assunto de um certificado TLS é o campo usado pelos serviços de detecção de DNS. O campo Nome do Assunto liga um certificado a um determinado servidor ou nome de domínio.

Nome do assunto significa um nome distinto X.500 que consiste em um ou mais nomes distintos relativos, também conhecidos como RDN. A tabela a seguir lista os nomes distintos relativos mais usados na identificação de organizações ou entidades de servidor.

Os códigos de País/Região são do ISO 3166-1. Para obter mais informações, consulte Nomes de país em inglês e elementos de código.

Componente de Domínio e País/Região são, por convenção, reciprocamente exclusivos. É uma prática recomendada referenciar o nome por País/Região ou por DNS. Além disso, lembre-se de que o tamanho máximo do Componente de Domínio (255 caracteres) é o total de todos os valores de Componente de Domínio.

Implementando nomes distintos relativos

Nomes de assunto são representados no cmdlet New-ExchangeCertificate como um parâmetro único que consiste em uma série de nomes separados por vírgula. Cada nome é identificado pela abreviação do nome distinto relativo. Por exemplo, o seguinte nome de assunto representa País/Região = US, Organização = Contoso Corp e Nome Comum = mail1.contoso.com:

-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

Outros exemplos de nomes de assunto que podem representar o mesmo servidor:

-SubjectName  "O=contoso corp, CN=mail1.contoso.com"
-SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com"
-SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

Quando você tem um nome DNS registrado, que usa para enviar email SMTP, é prática recomendada usar a convenção de componente de domínio e o nome DNS como nome do certificado, por exemplo, DC=contoso, DC=com, CN=mail1.contoso.com.

Entretanto, ao gerar uma solicitação de certificado de um fornecedor de CA, é preciso compreender os requisitos da CA para o campo Nome do Assunto e suas necessidades de PKI exclusivo. Em alguns casos, você poderá ter de usar o código de País/Região ("C"). Se esse for o caso, registre o nome distinto relativo em uma autoridade de registro X.500.

Nomes de assunto internacionais

Para nomes de assunto que contêm caracteres diferentes de ASCII, você pode digitar o parâmetro SubjectName como nome distinto entre aspas, como a seguir:

-SubjectName "C=ES,O=Diversión de Bicicleta,CN=mail1. DiversiondeBicicleta.com"

Nomes de assunto e Nomes de domínio

Por convenção, um nome comum pode conter um nome de domínio totalmente qualificado (FQDN). Embora essa prática seja difundida e recomendada, você deve entender as duas seguintes questões.

Em primeiro lugar, o tamanho máximo do campo de nome comum é de 64 caracteres. São menos caracteres do que o tamanho máximo de um FQDN. Portanto, para FQDN com mais de 64 caracteres, será preciso colocar o nome de domínio no Nome de Assunto Alternativo. DomainName é o parâmetro mapeado para o Nome de Assunto Alternativo no certificado resultante.

Em segundo lugar, o FQDN está restrito a um subconjunto do conjunto de caracteres ASCII. Entretanto, o nome comum (CN) aceita Unicode. Portanto, você pode criar um certificado válido com um CN semelhante a um nome DNS, mas trata-se de um DNS inválido. O software que estiver procurando um FQDN em um CN de certificado não retornará o resultado correto se o CN contiver caracteres diferentes de ASCII. Por exemplo, se você criasse um certificado com um Nome de Assunto, onde CN=mail.mïcrosoft.com, o nome seria ignorado como FQDN porque contém um caractere Unicode (o caractere ï com o diacrítico (x00ef)). A olho nu, o CN Unicode pode ser facilmente confundido com um FQDN, por causa da pequena diferença entre o caractere ï com o diacrítico (x00ef) e o ASCII i (x0069). A tarefa de certificação do Exchange não exige ou impõe que o CN do assunto seja um FQDN válido. Por padrão, isso significa que o cmdlet inclui o FQDN do servidor como CN padrão.

Nomes de domínio de certificado

Para o TLS, os certificados devem conter nomes DNS, já que o TLS é um protocolo baseado em DNS. Os clientes verificam o nome DNS do servidor ao qual estão se conectando, com o nome DNS ao qual esperam se conectar. Isso vale para navegadores que se conectam a sites por HTTPS e para servidores SMTP que transmitem email pela Internet ou intranet.

Um único servidor pode fornecer suporte para vários nomes DNS, pelos seguintes motivos:

• Um servidor SMTP tem suporte para vários domínios aceitos

• Um cliente pode acessar um servidor de email por nome de servidor, por nome de domínio, por um nome FQDN local ou por um nome balanceado por carga.

Quando uma conexão TLS for estabelecida, se o cliente encontrar o nome que está procurando, ele ignorará os outros nomes no certificado. Vários nomes de domínio e de servidor podem ser adicionados ao campo Nome de Assunto Alternativo de um certificado TLS. Você pode criar um certificado que contenha vários Nomes de Assunto Alternativos, usando o parâmetro DomainName do cmdlet New-ExchangeCertificate. O parâmetro DomainName é de valor múltiplo, por isso pode aceitar diversos nomes.

Certificados X.509 podem conter zero, um ou mais nomes DNS na extensão de certificado Nome de Assunto Alternativo (SubjectAltName). Nomes DNS na extensão SubjectAltName combinam exatamente as restrições de um nome DNS. Eles não devem ter mais de 255 caracteres e devem consistir nos caracteres A-Z, a-z, 0-9 e traço (-).

Lógica de correspondência de nome para o recurso Segurança de Domínio

A lógica de correspondência de nome de certificado para o recurso Segurança de Domínio verifica se um nome de domínio no certificado recebido corresponde ao nome de domínio quando ele envia mensagens a esse domínio. Para fins de exemplo, considere o FQDN do domínio de destinatário, woodgrovebank.com. A lógica de correspondência de nome de certificado pesquisa em todos os nomes DNS nos certificados e, desde que um nome DNS corresponda, o certificado é confirmado como correspondente ao domínio especificado.

Nesse exemplo, a lógica de correspondência de nome de certificado aceita um certificado com correspondência de domínio exata, como woodgrovebank.com. Ela aceita também o uso de nomes de domínio com caractere curinga nos certificados, de modo que um certificado com o nome DNS *.woodgrovebank.com seja aceito como correspondente. Para obter mais informações sobre nomes de domínio com caractere curinga, consulte "Nomes de domínio com caractere curinga" mais adiante neste tópico.

A lógica de correspondência de nome de certificado também pesquisa DNS no nível de um nó. Por essa razão, mail1.woodgrovebank.com também é aceito como correspondência para woodgrovebank.com. Entretanto, nomes DNS com nível de mais de dois nós não são aceitos. Portanto, mail1.us.woodgrovebank.com, por exemplo, não seria aceito como correspondência para woodgrovebank.com.

Para obter mais informações sobre como o Exchange seleciona certificados, consulte Seleção de certificado TLS SMTP (página em inglês).

Práticas recomendadas de nomes de domínio para Internet SMTP

Ao criar um certificado ou uma solicitação de certificado em um servidor de Transporte de Borda que executa SMTP TLS pela Internet, o conjunto de nomes de domínio que você deverá incluir na solicitação é:

• O nome de domínio totalmente qualificado da Internet do servidor   Pode ser diferente do FQDN interno usado entre os servidores de Transporte de Borda e Transporte de Hub e deve corresponder ao registro A, publicado no servidor DNS da Internet (público). Esse nome deve ser especificado como CN no parâmetro SubjectName do cmdlet New-ExchangeCertificate.

• Todos os nomes de domínio aceitos da organização   Use o parâmetro IncludeAcceptedDomain do cmdlet New-ExchangeCertificate para preencher o Nome de Assunto Alternativo do certificado resultante.

• O FQDN do conector se ele não for coberto por nenhum dos itens anteriores   Use o parâmetro DomainName do cmdlet New-ExchangeCertificate para preencher o Nome de Assunto Alternativo do certificado resultante.

Práticas recomendadas de nomes de domínio em um servidor de Acesso para Cliente

Ao criar um certificado ou uma solicitação de certificado em um servidor de Acesso para Cliente, o conjunto de nomes de domínio que você deverá incluir na solicitação é:

• Nome local ou de NetBIOS do servidor, por exemplo, owa1

• Todos os nomes de domínio aceitos da organização, por exemplo, contoso.com

• O nome de domínio totalmene qualificado do servidor, por exemplo, owa1.contoso.com

• O nome do domínio de Descoberta Automática, por exemplo, Autodiscover.contoso.com

• A identidade de equilíbrio de carga do servidor, se você estiver usando uma, por exemplo, owa.contoso.com

Nomes de domínio de caractere curinga

Nomes de domínio de caractere curinga são um tipo especial de nome de domínio que representa diversos subdomínios. Esses nomes podem simplificar os certificados, uma vez que um único nome de domínio de caractere curinga representa todos os subdomínios desse domínio. Eles são representados por um asterisco ( * ) no nó DNS. Por exemplo, *.contoso.com representa contoso.com e todos os subdomínios de contoso.com. Ao usar um caractere curinga para criar um certificado ou uma solicitação de certificado para todos os domínios aceitos, você pode simplificar bastante a solicitação.

Clonando um certificado existente

O Exchange 2007 cria um certificado auto-assinado durante a instalação que usa todos os nomes de domínio e de servidor conhecidos do Exchange no momento da instalação. Esses certificados são válidos por 12 meses. Em alguns casos, pode fazer sentido clonar esses certificados quando o Assunto e Nomes de Assunto Alternativos podem ser usados em outros computadores. Lembre-se de que apenas os metadados do certificado, e não os conjuntos de chave, são clonados.

Para executar os seguintes cmdlets em um computador em que a função de servidor Transporte de Borda esteja instalada, faça logon com uma conta que seja membro do grupo Administradores local no mesmo computador.

Para clonar um novo certificado de um existente, primeiramente identifique o certificado atual do domínio, executando o seguinte comando:

Get-ExchangeCertificate -DomainName mail1.contoso.com

Onde mail1.contoso.com é o nome do servidor ou o FQDN cujo certificado clonado deve ser criado.

O primeiro certificado listado na saída é o certificado SMTP TLS padrão do servidor.

Para clonar o certificado, execute o seguinte comando:

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

Onde o valor de Thumbprint provém do primeiro certificado listado na saída de Get-ExchangeCertificate.

Esse comando extrai os nomes do certificado existente que são identificados pela impressão digital e os utiliza no novo certificado auto-assinado.

Gerando solicitações de serviços de certificado de terceiros

Se estiver usando uma CA para gerar certificados, forneça uma solicitação de certificado de acordo com os requisitos da CA.

Para gerar uma solicitação de certificado, use o cmdlet New-ExchangeCertificate. Para gerar uma solicitação de certificado, use o parâmetro GenerateRequest com o parâmetro Path para definir onde o arquivo de solicitação será criado. O arquivo resultante será um arquivo PKCS #10 (.req) de solicitação. PKCS #10 é o Padrão de Sintaxe de Solicitação de Certificado especificado pelo RFC 2314 (http://www.ietf.org/rfc/rfc2314.txt).

Os exemplos a seguir mostram algumas solicitações de certificado típicas.

O primeiro exemplo gera uma solicitação de certificado no servidor da Contoso, mail1. O CN do Nome do Assunto contém o FQDN do servidor e o Nome de Assunto Alternativo contém todos os domínios aceitos em Contoso.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=us, o=contoso corp, cn=mail1.contoso.com" -IncludeAcceptedDomains -Path c:\certificates\mail1.contoso.com.req

O segundo exemplo gera uma solicitação de certificado no servidor da Contoso, mail1. A Contoso tem um conector de envio em cada servidor de Transporte de Borda que possui um FQDN de mail.contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=US, O=contoso corp, CN=mail1.contoso.com" -IncludeAcceptedDomains -DomainName mail.contoso.com -Path c:\certificates\mail1.contoso.com.req

O terceiro exemplo cria a solicitação de um certificado existente de Contoso.com.

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -Path c:\ certificates\mail1.contoso.com.req

O último exemplo mostra como criar uma solicitação de certificado com um caractere curinga para todos os subdomínios de Contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -DomainName *.contoso.com -Path c:\ certificates\mail1.contoso.com.req

Para obter mais exemplos, consulte a entrada no Blog da Equipe do Microsoft Exchange, Lições aprendidas: Gerando um Certificado com um CA de terceiros.

Instalando certificados emitidos por solicitações de certificado

Após enviada a solicitação de certificado para a CA, a CA emite um certificado ou uma cadeia de certificados. Em ambos os casos, os certificados são entregues como arquivos que você deve instalar com o cmdlet Import-ExchangeCertificate.

O exemplo a seguir mostra como importar um certificado de SMTP TLS

Import-ExchangeCertificate -Path c:\certificates\newcert.cer | Enable-ExchangeCertificate -Services SMTP

O próximo exemplo mostra como importar um certificado e habilitá-lo em um servidor de Acesso para Cliente que ofereça suporte para clientes POP3.

Import-ExchangeCertificate -Path c:\certificates\newcert.p7b | Enable-ExchangeCertificate -Services IIS,POP

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 certificação e criptografia, consulte as seguintes publicações:

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

• Práticas recomendadas para implementar uma infra-estrutura de chave pública do Microsoft Windows Server 2003