Noções Básicas Sobre Certificados TLS
Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Tópico modificado em: 2016-11-28
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 computador específico, você pode usar 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).
Procurando tarefas de gerenciamento relacionadas aos certificados TLS? Consulte Certificados.
Sumário
Campos usados por certificados de serviços TLS
Seleção de certificado
Criando certificados TLS
Referências
Campos usados por certificados de serviços TLS
Se você estiver usando o cmdlet New-ExchangeCertificate para gerar uma solicitação de certificado de terceiros ou de outra autoridade de certificação (CA) de infraestrutura 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 diferenciado 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.
| Nome | Abreviação | Tipo | Tamanho máximo | Freqüência Máx.\Recomendável em certificado\solicitação | Ordem no assunto |
|---|---|---|---|---|---|
País/Região |
C |
ASCII |
2 |
1\1 |
1 |
Componente de Domínio |
DC |
ASCII |
255 |
Muitas |
1 |
Estado |
S |
Unicode |
128 |
1 |
2 |
Localidade |
L |
Unicode |
128 |
1 |
3 |
Organização |
O |
Unicode |
64 |
1\1 |
4 |
Unidade Organizacional |
OU |
Unicode |
64 |
Muitas\Muitas |
5 |
Nome Comum |
CN |
Unicode |
64 |
Muitas\1 |
6 |
Os códigos de País/Região são do ISO 3166-1. Para 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.
Importante
Embora os certificados possam ter mais de um campo de nome comum, alguns serviços são implementados presumindo-se haver apenas um nome comum. Portanto, vários nomes comuns podem causar problemas de interoperabilidade. É recomendável que o certificado ou a solicitação de certificado criados contenha apenas um nome comum.
Especificando nomes distintos relativos
Ao criar solicitações de certificados usando o cmdlet New-ExchangeCertificate, os nomes de assunto são representados 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 diferenciado 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 diferenciado 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 um nome diferenciado 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, 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 FQDNs 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)). De relance, 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 depende do 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. Por 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.
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 IncludeAcceptedDomains 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.
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.
Seleção de certificado
O Exchange segue processos de seleção de certificado diferentes dependendo do tipo de conexão SMTP.
Quando os servidores de Transporte de Hub estão se comunicando uns com os outros ou com os servidores de Transporte de Borda em sua organização, certificados de TLS anônimos são usados. Para mais informações, consulte Seleção de certificados TLS anônimos de entrada e Seleção de certificados TLS anônimos de saída.
Quando um host ou cliente SMTP se conecta aos servidores de Transporte de Hub ou de Borda, o processo de seleção de certificado STARTTLS é usado. Para mais informações, consulte Seleção de certificados STARTTLS de entrada.
Criando certificados TLS
O Exchange 2010 cria um certificado autoassinado durante a instalação que utiliza todos os nomes de domínio e de servidor conhecidos pelo Exchange no momento da instalação. É possível clonar esse certificado para usá-lo em servidores adicionais. Você pode também substituir esse certificado por certificados emitidos por uma CA de terceiros. Os tópicos a seguir fornecem instruções passo a passo para cada tarefa.
Referências
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.
Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2ª edição. Nova York: John Wiley & Son, Inc., 1996.
© 2010 Microsoft Corporation. Todos os direitos reservados.