24/1/2014 Julio Battisti

Tutorial de TCP/IP – Parte 19 – Certificados Digitais e

Segurança
Introdução:

Esta é a décima nona parte do Tutorial de TCP/IP. Na Parte 1 tratei dos aspectos
básicos do protocolo TCP/IP. Na Parte 2falei sobre cálculos binários, um importante
tópico para entender sobre redes, máscara de sub-rede e roteamento. Na Parte 3 falei
sobre Classes de endereços, na Parte 4 fiz uma introdução ao roteamento e na Parte
5apresentei mais alguns exemplos e análises de como funciona o roteamento e
na Parte 6 falei sobre a Tabela de Roteamento. Na Parte 7 tratei sobre a divisão de uma
rede em sub-redes, conceito conhecido como subnetting. NaParte 8 fiz uma
apresentação de um dos serviços mais utilizados pelo TCP/IP, que é o Domain Name
System: DNS. O DNS é o serviço de resolução de nomes usado em todas as redes
TCP/IP, inclusive pela Internet que, sem dúvidas, é a maior rede TCP/IP existente.
Na Parte 9 fiz uma introdução ao serviço Dynamic Host Configuration Protocol – DHCP.
Na Parte 10 fiz uma introdução ao serviço Windows Internet Name Services – WINS.
Na Parte 11 falei sobre os protocolos TCP, UDP e sobre portas de comunicação.
Na Parte 12, mostrei como são efetuadas as configurações de portas em diversos
aplicativos que você utiliza e os comandos do Windows 2000/XP/2003 utilizados para
exibir informações sobre portas de comunicação. Na Parte 13 falei sobre a instalação e
a configuração do protocolo TCP/IP. Na Parte 14 fiz uma introdução sobre o protocolo
de roteamento dinâmico RIP e na Parte 15 foi a vez de fazer a introdução a um outro
protocolo de roteamento dinâmico, o OSPF. NaParte 16 você aprendeu sobre um
recurso bem útil: O compartilhamento da conexão Internet, oficialmente conhecida
como ICS – Internet Connection Sharing. Este recurso é útil quando você tem uma
pequena rede, não mais do que cinco máquinas, conectadas em rede, todas com o
protocolo TCP/IP instalado e uma das máquinas tem conexão com a Internet. Você
pode habilitar o ICS no computador que tem a conexão com a Internet. Com isso os
demais computadores da rede também passarão a ter acesso à Internet.. Na Parte 17,
você aprendeu a utilizar o IFC – Internet Firewall Connection (Firewall de Conexão com
a Internet). O IFC faz parte do Windows XP e do Windows Server 2003, não estando
disponível no Windows 2000.O IFC tem como objetivo proteger o acesso do
usuário contra “ataques” e “perigos” vindos da Internet. Na Parte 18 fiz uma
apresentação sobre o protocolo IPSec. O IPSec faz parte do Windows 2000, Windows
XP e Windows Server 2003. O IPSec pode ser utilizado para criar um canal de
comunicação seguro, onde todos os dados que são trocados entre os computaodres
habilitados ao IPSec, são criptografados.

Nesta décima nona parte, farei uma apresentação sobre o conceito de PKI – Public Key
Infrastructure e Certificados Digitais. O Windows 2000 Server e também o Windows
Server 2003 disponibilizam serviços para a emissão, gerenciamento e revogação de
Certificados Digitais. Você também entenderá o papel dos Certificados Digitais em
relação à segurança das informações.

Apresentarei o conceito de PKI - Public Key Infrastructure (Infraestrutura de chave

pública). Você verá que uma Public Key Infrastructure (Infraestrutura de chave pública),
abreviada simplesmente como PKI, nada mais é do que uma infraestrutura de
segurança baseada em certificados digitais, em autoridades certificadores (CA –
Certificate Authorities - que emitem e revogam os certificados) e autoridades de
registro, as quais fazem a verificação da autenticidade de todas as estruturas
envolvidas em uma PKI.

http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 1/11
24/1/2014 Julio Battisti

Nesta parte do tutorial você entenderá o que vem a ser uma PKI, aprenderá sobre os
conceitos básicos de uso de um par de chaves para fazer a criptografia e proteção dos
dados. Também mostrarei qual o papel do Microsoft Certification Service, que é o
servidor da Microsoft para a emissão e controle de certificados digitais, serviço este
disponível no Windows 2000 Server e também no Windows Server 2003. Com o uso
do Microsoft Certificate Services, a empresa pode montar a sua própria infraestrutura
de certificados digitais, sem depender de uma autoridade certificadora externa.

Nota: Para aprender a instalar, configurar e a administrar o Microsoft Certificate

Services, consulte o Capítulo 7 do meu livro: Manual de Estudos Para o Exame 70-216,
712 páginas.

O uso de Certificados e uma infra-estrutura de chave pública é uma alternativa de baixo

custo, para ambientes que precisam de níveis de segurança elevados, como por
exemplo departamentos de pesquisa de novos produtos e tecnologias, ou órgãos
governamentais estratégicos, como os órgãos de defesa e de segurança. Com o uso
do Microsoft Certificate Services é possível criar a administrar uma estrutura de
segurança baseada em Certificados Digitais.

Microsoft Certificate Services e PKI

Neste tópico apresentarei o conceito de PKI e de criptografia baseada em um par de

chaves de criptografia: uma chave pública e uma chave privada. Você verá que os
Certificados digitais tem papel fundamental em uma estrutura de PKI. Neste tópico você
também aprenderá a instalar e a configurar o Microsoft Certificate Services.

Uma introdução sobre Certificados e PKI – Public Key Infrastructure

Segurança mais do que nunca é um assunto sempre em pauta. De tempos em tempos

um novo vírus causa pânico na Internet, novos tipos de ataques são notificados, sites
ficam indisponíveis devido a ataques de hackers, problemas com a segurança no acesso
a dados que facilitam a vida de fraudadores e por aí vai.

No Windows 2000, Windows XP e no Windows Server 2003 existem diversas maneiras

de proteger seus dados: permissões NTFS, criptografia, uso do NAT para acesso à
Internet, uso de Group Policy Objects, uso de diretivas de segurança, direitos de
usuários e por aí vai. Neste tópico, abordarei mais um assunto relacionado com
segurança: Certificados Digitais.

Uma pergunta que o amigo leitor poderia fazer é a seguinte: “Por que existem tantos
ataques de segurança e por que os hackers parecem conhecer tão bem os sistemas
das empresas?”.

Um dos motivos é porque hoje o mundo inteiro (literalmente) utiliza o mesmo

protocolo para comunicação e troca de dados: TCP/IP. Como o TCP/IP é amplamente
conhecido e documentado, esta informação também é utilizada por hackers, para
tentar descobrir falhas no próprio protocolo, falhas estas que permitam quebra de
segurança dos sistemas informatizados das empresas. Evidentemente que, na maioria
das vezes, os ataques são bem sucedidos, porque os programas foram instalados com
as opções padrão (out of the Box – como saíram da caixa (a tradução é por minha
conta e risco)), sem se preocupar em ajustar devidamente as configurações de
segurança.

Nota: Um dos pontos onde o Windows Server 2003 melhorou, e muito, em relação ao
Windows 2000 Server foi nas configurações de segurança out of the Box. Ou seja, as
http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 2/11
24/1/2014 Julio Battisti

configurações padrão de segurança do Windows Server 2003, são bem mais severas,
restringem bem mais o acesso do que as configurações padrão de segurança do
Windows 2000 Server. A idéia é simples mas muito eficiente. Por padrão, o nível
mínimo de acesso, necessário ao funcionamento do recurso. Se houver necessidade de
modificações nas configurações de segurança, estas poderão ser feitas pelo
administrador.

Com o uso do TCP/IP como protocolo de comunicação, os dados não são protegidos
por padrão, isto é, não são criptografados. Ou seja, se um hacker interceptar uma
transmissão, terá acesso aos dados sem maiores problemas, uma vez que não é
usada criptografia, por padrão. Claro que para muitas situações, a criptografia e outros
recursos de segurança são perfeitamente dispensáveis. Por exemplo, quando você
acessa o site de uma empresa para obter informações gerais sobre a empresa. Estas
informações são de domínio público (afinal estão no site da empresa) e não há
necessidade de criptografá-las. Agora quando você faz uma compra pela Internet,
usando o seu cartão de crédito, ou quando você faz transações bancárias usando o site
do seu Banco, a coisa muda completamente de figura. Ou seja, você quer o máximo de
segurança possível. De maneira alguma você gostaria que alguém pudesse interceptar o
seu número de conta, agência e senha.

Inicialmente criou-se um método de criptografia, onde os dados eram criptografados

usando uma determinada chave de criptografia. A chave é um código com um
determinado número de bits. Usa-se este código, juntamente com operações lógicas,
para “embaralhar”, ou seja, criptografar os dados. A seqüência de operações lógicas
que é realizada com os dados, usando a chave de criptografia, é definida pelo algoritmo
de criptografia. Em seguida os dados e a chave de criptografia são enviados para o
destinatário. O destinatário recebe os dados e a chave de criptografia e utiliza esta
chave para “descriptografar” os dados. Um método bem seguro, não?

Não. Este método tem dois problemas principais, os quais são descritos a
seguir:

1. A chave de criptografia é enviada junto com os dados: Com isso, se um

hacker interceptar os dados, terá também acesso a chave de criptografia. Usando a
chave (os algoritmos de criptografia são de domínio público, a segurança é baseada
normalmente no tamanho da chave. Usam-se chaves com um grande número de bits,
para que seja difícil descobrir a chave que está sendo utilizada) o hacker poderá
descriptografar os dados e ter acesso ao conteúdo da mensagem. Pior, o hacker
poderia alterar a mensagem e enviá-la, alterada, para o destinatário, o qual não teria
como saber que a mensagem foi alterada.

2. No final do parágrafo anterior eu descrevo o segundo problema com este

método: ele não permite a verificação da identidade de quem envio a
mensagem. Ou seja, um hacker interceptou a mensagem, usou a chave para
descriptografá-la, alterou a mensagem e a enviou para o destinatário. O destinatário
recebe a mensagem e não tem como verificar se a mensagem veio do emissor
verdadeiro ou veio de um hacker. Com este método não é possível verificar e garantir
que o emissor seja quem ele diz ser. Não há como verificar a identidade do emissor.

Vejam que somente o uso da criptografia, baseada em uma chave privada (chave
enviada junto com a mensagem), não é tão seguro como pode parecer. Para
solucionar esta questão é que surgiram os Certificados Digitais, com os quais é possível
implementar uma infra-estrutura conhecida como PKI - Public Key Infrastructure
(Infraestrutura de chave pública). Esta infra-estrutura é baseada no uso de certificados
digitais e de um par de chaves: uma chave pública e uma chave privada. A seguir
http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 3/11
24/1/2014 Julio Battisti

descrevo os princípios básicos de um infra-estrutura baseada em chaves pública e

privada, para que você possa entender como esta infra-estrutura resolve os dois
problemas apontados no método anterior.

Em uma rede que usa PKI, um Certificado Digital é criado para cada usuário. O
Certificado Digital fica associado com a conta do usuário no Active Directory. Para cada
usuário é criado um par de chaves: uma chave pública e uma chave privada. A chave
pública fica disponível no Active Directory e a chave privada fica com o usuário. O mais
comum é a chave privada ficar gravada no Certificado Digital do usuário, em um
disquete que fica com o usuário ou, mais comum ainda, em um Smart Card. Agora
vamos entender como funciona a criptografia baseada em um par de chaves: uma
pública e outra privada.

Dados que são criptografados com uma das chaves, somente poderão ser
descriptografados com a outra chave. Por exemplo, se você criptografar dados com a
chave pública do usuário jsilva, estes dados somente poderão ser descriptografados
com a chave privada do usuário jsilva.

Vamos imaginar que o usuário jsilva precisa enviar dados para o usuário maria. Os
dados são criptografados com a chave pública do usuário Maria – chave pública do
destinatário. Com a infraestrutura de PKI, as chaves públicas ficam disponíveis para
serem acessadas por quaisquer usuário. A chave pública fica gravada no Certificado
Digital do usuário e a lista de Certificados Digitais fica publicada para acesso em um
servidor de certificados digitais (este é o papel do Microsoft Certificate Services, ou
seja, emitir, publicar, dar acesso a e revogar certificados digitais para os usuários).

A chave pública do usuário maria é utilizada pelo usuário jsilva para criptografar os
dados, antes de enviá-los para o usuário maria. Como os dados foram criptografados
com a chave pública do usuário maria, a pergunta é: qual a única chave que poderá
descriptografar estes dados? A chave privada do usuário maria, a qual somente
o usuário maria tem acesso. Com este método, quando o usuário maria recebe os
dados, ele utilizará a sua chave privada para descriptografá-los. Se um hacker
interceptar os dados, ele não conseguirá descriptografá-los, pois não tem acesso a
chave privada do usuário maria. Observe que com este método, a chave que será
utilizada para descriptografar os dados, não é enviada junto com a mensagem. Além
disso, a mensagem é criptografada de tal maneira que somente o destinatário é capaz
de descriptografá-la, ou melhor, a chave privada do destinatário. Como a mensagem é
criptografada com a chave pública do destinatário, somente o próprio destinatário (que
é quem tem acesso a sua chave privada), será capaz de descriptografar a mensagem.

Observe que com este método é solucionado o problema de ter que enviar a chave de
criptografia junto com a mensagem. O problema de verificação da identidade, de ter
certeza que o remetente é quem diz realmente ser, é solucionado com o uso de
Certificados digitais. De uma maneira simples, podemos resumir uma PKI como sendo
uma infra-estrutura de segurança, baseada no uso de um par de chaves (uma pública e
uma privada) e de Certificados Digitais.

Um pouco sobre Certificados Digitais

De uma maneira simples, o Certificado Digital é a versão eletrônica da sua identificação

de usuário na rede (usuário e senha). O Certificado Digital é como se fosse a
“carteira de identidade” do usuário na rede. No Windows 2000 Server e no
Windows Server 2003, o certificado digital do usuário também é conhecido (na
documentação oficial), como um Certificado de chave pública, uma vez que uma das
informações gravadas no certificado digital do usuário é justamente a sua chave
http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 4/11
24/1/2014 Julio Battisti

pública.

Um certificado de chave pública, geralmente chamado somente de certificado, é uma

declaração assinada digitalmente que vincula o valor de uma chave pública à identidade
da pessoa (conta do usuário no Active Directory), dispositivo ou serviço que contém a
chave privada correspondente.

Os Certificados Digitais podem ser emitidos para uma série de funções, tais como
autenticação de usuário na Internet, autenticação de um servidor Web, correio
eletrônico seguro (S/MIME), IPSec, para utilização com o protocolo Transaction Layer
Security (TLS, segurança de camada de transação) e assinatura de códigos (por
exemplo, todos os programas desenvolvidos pela Microsoft são assinados,
digitalmente, com o Certificado digital da Microsoft. O Windows 2000 Server pode ser
configurado para não instalar drives ou programas que não estejam assinados
digitalmente ou cujos certificados com os quis foram assinados, não possam ser
verificados quanto a sua autenticidade).

Os certificados digitais tem que ser emitidos por uma Autoridade Certificadora (CA –
Certificate Authority). Uma opção é usar uma autoridade certificadora externa, como
por exemplo a Veri Sign, que é uma empresa especializada em segurança e em
certificação digital (www.verisign.com). Com o Windows 2000 Server (e também com
o Windows Server 2003), está disponível o Microsoft Certificate Services, que é um
servidor que permite criar uma autoridade certificadora na própria rede da empresa,
sem ter que fazer uso de uma entidade certificadora externa. Ao utilizar o Certificate
Services para a emissão e gerenciamento de certificados, os certificados digitais
poderão ser utilizados pelos usuários, para fazer o logon na rede. Os certificados
também são emitidos de uma autoridade de certificação para outra a fim de
estabelecer uma hierarquia de certificação. Usando o Certificate Services você poderá
criar uma hierarquia de certificação na rede da empresa.

A maioria dos certificados em uso hoje em dia são baseados no padrão X.509. Esta é a
tecnologia fundamental usada na public key infrastructure (PKI) do Windows 2000 e do
Windows Server 2003.

Normalmente, os certificados contêm as seguintes informações:

Chave pública do usuário

Informações da identificação do usuário (como o nome e o endereço de correio eletrônico)
Período de validade (o período de tempo em que o certificado é considerado válido)
Informações sobre a identificação do emissor do certificado.
A assinatura digital do emissor, que atesta a validade da ligação entre a chave pública do
usuário e as informações de identificação do usuário.

Um certificado só é válido pelo período de tempo nele especificado, ou seja, o

certificado tem prazo de validade e tem que ser renovado periodicamente. Esta é uma
medida importante para aumentar o nível de segurança, pois a cada renovação, um
novo par de chaves é gerado. Cada certificado contém datas “Válido de” e “Válido até”,
que limitam o período de validade. Depois que o período de validade de um certificado
terminar, um novo certificado deve ser solicitado pelo usuário do agora expirado
certificado.

Em situações em que seja necessário desabilitar um certificado, este pode ser revogado
pelo emissor. Cada emissor mantém uma lista de certificados revogados (CRL –
Certification Revocation List), a qual é usada pelos programas quando a validade de um
determinado certificado está sendo verificada. Por exemplo, programas que usam
certificados para autenticação, ao receberem uma tentativa de acesso, primeiro entram
em contato com a autoridade certificadora (no caso do Windows 2000 Server um
http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 5/11
24/1/2014 Julio Battisti

servidor com o Microsoft Certificate Services) para verificar se o certificado que está
sendo apresentado para logon, não está na lista dos certificados revogados – CRL. Se o
certificado estiver na CRL, o logon será negado.

Certificados e Autoridades de Certificação

Todo certificado é emitido por uma Autoridade de Certificação (CA – Certificate

Authority). A autoridade de certificação, a partir de agora denominada apenas CA, é
responsável pela verificação sobre a veracidade dos dados do usuário que está
requisitando o certificado. Por exemplo, qualquer usuário pode solicitar um certificado
para utilizar na Internet. Para obter o certificado ele precisa utilizar os serviços de uma
CA, como por exemplo a VeriSign (www.verisign.com).

Uma autoridade de certificação é uma entidade encarregada de emitir certificados para

indivíduos, computadores ou organizações, sendo que os certificados é que confirmam
a identidade e outros atributos do usuário do certificado, para outras entidades. Uma
autoridade de certificação aceita uma solicitação de certificado, verifica as informações
do solicitador (incluindo aí uma série de documentos e comprovantes, os quais devem
ser apresentados pelo solicitante do certificado) e, em seguida, usa sua chave privada
para aplicar a assinatura digital no certificado. A autoridade de certificação emite então
o certificado para que o usuário do certificado o use como uma credencial de segurança
dentro de uma infra-estrutura de chave pública (PKI). Uma autoridade de certificação
também é responsável por revogar certificados e publicar uma lista de certificados
revogados (CRL).

Uma autoridade de certificação pode ser uma empresa que presta o serviço de
autoridade certificadora, como o VeriSign, ou pode ser uma autoridade de certificação
que você cria para ser usada por sua própria organização, instalando os Serviços de
certificados do Windows 2000 Server ou do Windows Server 2003. Cada autoridade de
certificação pode ter requisitos diferentes de prova de identidade, como uma conta de
domínio do Active Directory, crachá de empregado, carteira de motorista, solicitação
autenticada ou endereço físico. Verificações de identificação como essa geralmente
asseguram uma autoridade de certificação no local, de tal modo que as organizações
possam validar seus próprios empregados ou membros.

As autoridades de certificação corporativas do Windows 2000 Server usam as

credenciais da conta de usuário do Active Directory de uma pessoa, como prova de
identidade. Em outras palavras, se você tiver efetuado logon em um domínio do
Windows 2000 Server e solicitar um certificado de uma autoridade de certificação
corporativa, a autoridade de certificação saberá que você é quem o Active Directory
“diz que você é”.

Todas as autoridades de certificação têm um certificado para confirmar sua própria

identidade, emitido por outra autoridade de certificação confiável ou, no caso de
autoridades de certificação raiz, emitido por elas mesmas. É importante lembrar que
qualquer pessoa pode criar uma autoridade de certificação. A questão real é se você,
como um usuário ou um administrador, confia naquela autoridade de certificação e, por
extensão, nas diretivas e procedimentos que ela emprega para confirmar a identidade
dos certificados emitidos para entidades por essa autoridade de certificação.

Em uma rede baseada no Windows 2000 Server (ou no Windows Server 2003), o
administrador também pode utilizar uma CA externa. Porém, com o uso do Microsoft
Certificate Services, o administrador pode criar sua própria autoridade certificadora. O
Certificate Services da Microsoft permite a criação de sofisticados ambientes de
certificação, com a criação de uma hierarquia de CAs. Com o uso do Certificate
http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 6/11
24/1/2014 Julio Battisti

Services podem ser criadas os seguintes tipos de autoridades certificadoras, os quais

serão descritos mais adiante:

Enterprise Root CA.

Enterprise Subordinate CA.
Standalone Root CA.
Standalone Subordinate CA

Ao criar uma estrutura interna para criação e gerenciamento de certificados digitais,

você deve definir os procedimentos que serão utilizados para verificar a veracidade dos
dados dos usuários que estão solicitando certificados. Por exemplo, você pode utilizar
as informações do Active Directory, como sendo as informações oficiais de cada
funcionário, porém o funcionário tem acesso a alterar as informações da sua conta no
Active Directory. Com isso você terá que montar uma metodologia formal de
verificação (um pouco de burocracia as vezes se faz necessária). Por exemplo, você
pode solicitar que o chefe imediato do funcionário confirme os dados em um formulário
na Intranet da empresa (formulário de papel também já seria demais).

A existência de uma autoridade certificadora significa que você tem confiança de que a
autoridade de certificação possui as diretivas corretas no local correto e ao avaliar as
solicitações de certificado, irá negar certificados para qualquer entidade que não atender
a essas diretivas. Esta é uma questão fundamental para garantir a identidade dos
usuários. Ao fazer uma verificação rigorosa dos dados informados, antes de emitir um
certificado para um usuário, servidor ou computador, a CA garante que quem obtém o
certificado realmente é quem diz ser – prova de identidade. Por isso a importância
fundamental de definir uma metodologia clara, simples e de fácil execução, para a
verificação dos dados, antes de emitir os certificados.

Além disso, você confia que a autoridade de certificação irá revogar certificados que não
devem mais ser considerados válidos, através da publicação de uma lista de certificados
revogados, sempre atualizada (CRL – Certificate Revocation List). As listas de
certificados revogados são consideradas válidas até expirarem. Logo, mesmo que a CA
publique uma nova lista de certificados revogados com os certificados recém revogados
listados, todos os clientes que possuírem uma lista de revogação de certificados antiga
não irão procurar nem recuperar a lista nova até que a antiga expire ou seja excluída.
Os clientes podem usar uma página Web da CA para recuperar manualmente a lista de
certificados revogados mais atual, caso seja necessário.

Para serviços, computadores e usuários do Windows 2000 Server, a confiança em uma

autoridade de certificação é estabelecida quando você possui uma cópia do certificado
raiz no armazenamento das autoridades de certificação raiz confiáveis e tem um
caminho de certificação válido, significando que nenhum dos certificados no caminho de
certificação foi revogado ou que seus períodos de validade expiraram. O caminho de
certificação inclui todos os certificados emitidos para cada CA na hierarquia da
certificação de uma CA subordinada para a CA raiz. Por exemplo, para uma CA raiz, o
caminho de certificação é um certificado, seu próprio certificado auto-assinado. Para
uma CA subordinada, abaixo da CA raiz na hierarquia, seu caminho de certificação inclui
2 certificados, seu próprio certificado e o certificado da CA raiz.

Caso sua empresa esteja usando o Active Directory, a confiança nas autoridades de
certificação da organização será estabelecida automaticamente, baseada nas decisões
e configurações realizadas pelo administrador do sistema e nas relações de confiança
criadas automaticamente pelo Active Directory.

Os diferentes tipos de Autoridades Certificadores

http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 7/11
24/1/2014 Julio Battisti

Conforme descrito anteriormente, podem ser criados diferentes tipos de autoridades

certificadoras. Pode ser uma autoridade certificadora corporativa (Enterprise) ou
Autônoma (Standalone). Cada um destes tipos pode ser uma autoridade certificadora
root ou subordinada. Com isso ficamos com os quatro tipos possíveis de autoridades
certificadores:

Corporativa root CA
Corporativa subordinada CA
Autônoma root CA
Autônoma subordinada CA

Uma autoridade de certificação raiz, mais conhecida como autoridade root, é encarada
como o tipo mais confiável de autoridade de certificação na PKI de uma organização.
Geralmente, tanto a segurança física como a diretiva de emissão de certificados de uma
autoridade de certificação raiz são mais rigorosas do que as de autoridades de
certificação subordinadas.

Se a autoridade de certificação raiz estiver comprometida ou emitir um

certificado para uma entidade não autorizada, toda a segurança baseada em
certificados, da sua organização, estará vulnerável e não será mais confiável.
Enquanto as autoridades de certificação raiz podem ser usadas para emitir certificados
para usuários finais em tarefas como enviar correio eletrônico seguro, na maioria das
organizações elas são usadas apenas para emitir certificados para outras autoridades
de certificação, chamadas de subordinadas.

Uma autoridade de certificação subordinada é uma autoridade de certificação

que foi certificada por outra autoridade de certificação de sua organização, ou
seja, está subordinada a uma outra entidade certificadora. Se a entidade principal
deixar de ser confiável, todas as entidades subordinadas também o deixarão de ser.
Geralmente, uma autoridade de certificação subordinada emitirá certificados para usos
específicos, como correio eletrônico seguro, autenticação baseada na Web ou
autenticação de cartões inteligentes. Autoridades de certificação subordinadas também
podem emitir certificados para outras autoridades de certificação subordinadas em um
nível abaixo delas. Com isso é possível criar uma hierarquia de entidades certificadores.
Juntas, a autoridade de certificação raiz, as autoridades de certificação subordinadas
certificadas pela raiz e as autoridades de certificação subordinadas que foram
certificadas por outras autoridades de certificação subordinadas formam uma hierarquia
de certificação.

Autoridades de certificação corporativas

Você pode instalar o Microsoft Certificate Services para criar uma autoridade de
certificação corporativa, na Intranet da empresa. Autoridades de certificação
corporativas podem emitir certificados para várias finalidades, tais como assinaturas
digitais, correio eletrônico seguro usando S/MIME (extensões multipropósito do Internet
Mail protegidas), autenticação para um servidor Web seguro usando Secure Sockets
Layer (SSL, camada de soquetes de segurança) ou segurança da camada de transporte
(TLS) e logon em um domínio do Windows 2000 Server ou Windows Server 2003,
usando um cartão inteligente (smart card).

Uma autoridade de certificação corporativa apresenta as seguintes características e

exigências:

Uma autoridade de certificação corporativa exige o Active Directory.

Quando você instala uma autoridade de certificação corporativa raiz, ela é automaticamente
adicionada ao armazenamento de certificados das Autoridades de certificação raiz confiáveis,
http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 8/11
24/1/2014 Julio Battisti
para todos os usuários e computadores do domínio. Você precisa ser administrador de domínio
ou administrador com direito de gravação no Active Directory para instalar uma autoridade de
certificação corporativa raiz.

Todas as solicitações de certificados enviadas para a autoridade de certificação corporativa serão

atendidas ou negadas com base no conjunto de diretivas e permissões de segurança do tipo de
certificado solicitado. Autoridades de certificação corporativas nunca definem uma solicitação de
certificado como pendente. Elas imediatamente emitem o certificado ou negam a solicitação.

Os certificados podem ser emitidos para efetuar logon em um domínio do Windows 2000 Server
ou Windows Server 2003, usando cartões inteligentes (smart cards).

O módulo de saída corporativo publica certificados de usuários e a lista de certificados revogados

(CRL), no Active Directory. Para publicar certificados no Active Directory, o servidor em que a
autoridade de certificação está instalada deve ser membro do grupo de Certificates Publishers
(Publicadores de certificados). Isso é automático para o domínio em que o servidor está, mas a
autoridade de certificação precisará receber as permissões de segurança corretas para publicar
certificados em outros domínios.

Uma autoridade de certificação corporativa usa tipos de certificados, que são baseados
em um modelo de certificado. A seguinte funcionalidade é possível devido ao uso de
modelos de certificado:

As autoridades de certificação corporativas aplicam verificações de credenciais aos usuários

durante o registro de certificados. Cada modelo de certificado tem uma permissão de segurança
definida no Active Directory que determina se quem está solicitando o certificado está autorizado
a receber o tipo de certificado solicitado.

O nome do usuário do certificado é automaticamente gerado.

O módulo de diretiva adiciona uma lista predefinida de extensões de certificados ao certificado

emitido a partir do modelo do certificado. Isso reduz a quantidade de informações que a pessoa
que solicita o certificado precisa fornecer sobre o certificado e sobre o uso pretendido.

Os servidores que desempenham o papel de autoridades certificadoras corporativas,

desempenham um papel fundamental na estrutura de segurança da empresa. Por isso é
importante que você implemente políticas de backup e de segurança bem rigorosas em
relação a estes servidores.

Além da segurança lógica, no acesso aos dados, é muito importante cuidar também da
segurança física, controlando quem tem acesso ao servidor configurado como servidor
corporativo root.

Autoridades de certificação autônomas

Você pode instalar os serviços de certificados para criar uma autoridade de certificação
autônoma. Autoridades de certificação autônomas podem emitir certificados para
finalidades diversas, tais como assinaturas digitais, correio eletrônico seguro usando
S/MIME (extensões multipropósito do Internet Mail protegidas) e autenticação para um
servidor Web seguro usando camada de soquetes de segurança (SSL) ou segurança da
camada de transporte (TLS).

Uma autoridade de certificação autônoma tem as seguintes características:

Diferentemente de uma autoridade de certificação corporativa, uma autoridade de certificação

autônoma não exige o uso do Active Directory. Autoridades de certificação autônomas se
destinam principalmente a serem usadas quando extranets e a Internet estão envolvidas. Por
exemplo, se parceiros de negócios precisam se conectar a rede da empresa para acessar
determinados sistemas, você pode criar uma autoridade certificadora autônoma, para emitir
certificados para os parceiros de negócio. Estes, por sua vez, usarão estes certificados para se
identificar e ter acesso a rede da empresa. Além disso, se desejar usar um módulo de diretiva
personalizado para uma autoridade de certificação, você deve, primeiramente, instalar os
serviços de certificados usando diretiva autônoma e, em seguida, substituir a diretiva autônoma

http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 9/11
24/1/2014 Julio Battisti
pela sua diretiva personalizada.

Ao submeter uma solicitação de certificado a uma autoridade de certificação autônoma, o

solicitador do certificado deve fornecer, explicitamente, todas as informações de identificação
sobre si mesmo e sobre o tipo de certificado desejado na solicitação do certificado. (Não é
necessário fazer isso ao submeter uma solicitação a uma autoridade de certificação corporativa,
uma vez que as informações do usuário corporativo já estão no Active Directory e o tipo do
certificado é descrito por um modelo de certificado).

Por padrão, todas as solicitações de certificados enviadas para a autoridade de

certificação autônoma são definidas como pendentes até que o administrador da
autoridade de certificação autônoma verifique a identidade do solicitador e dê OK para a
solicitação. Isso é feito por razões de segurança, porque as credenciais do solicitador
do certificado não são verificadas pela autoridade de certificação autônoma.

Não são usados modelos de certificados, a exemplo do que acontece com as autoridades
certificadores corporativas.

Nenhum certificado pode ser emitido para efetuar logon em um domínio do Windows 2000 Server
ou do Windows Server 2003 usando cartões inteligentes, mas outros tipos de certificados podem
ser emitidos e armazenados em um cartão inteligente.

O administrador tem que distribuir, explicitamente, o certificado da autoridade de certificação

autônoma para o armazenamento de raiz confiável dos usuários do domínio, ou os usuários
devem executar essa tarefa sozinhos.

Quando uma autoridade de certificação autônoma usa o Active Directory, ela tem esses
recursos adicionais:

Se um membro do grupo de administradores de domínio ou um administrador com direito de

gravação no Active Directory instalar uma autoridade de certificação raiz autônoma, ela será
automaticamente adicionada ao armazenamento de certificados das autoridades de certificação
raiz confiáveis, para todos os usuários e computadores do domínio. Por essa razão, ao instalar
uma autoridade de certificação raiz autônoma em um domínio do Active Directory, você não
deverá alterar a ação padrão da autoridade de certificação até receber solicitações de
certificados (o que marca as solicitações como pendentes). Caso contrário, você terá uma
autoridade de certificação raiz confiável que automaticamente emite certificados sem verificar a
identidade do solicitador.

Se uma autoridade de certificação autônoma for instalada por um membro do grupo de

administradores de domínio do domínio pai de uma árvore na empresa, ou por um administrador
com direito de gravação no Active Directory, a autoridade de certificação autônoma publicará os
certificados e a lista de certificados revogados (CRL) no Active Directory.

Não esqueça: Conheça bem as diferenças entre os diferentes tipos de autoridades

certificadores. Lembre-se que autoridades certificadoras corporativas são integradas
com o Active Directory, utilizam modelos de certificados para a criação de novos
certificados. Já as autoridades certificadoras autônomas não dependem do Active
Directory e não utilizam modelos de certificados. A seguir um pequeno resumo sobre
cada um dos quatro tipos, para você fixar bem sobre a função e as características de
cada um dos tipos de autoridades certificadores:

1. Enterprise root CA – Autoridade certificadora corporativa root: Um único

servidor pode ser configurado como Enterprise root CA em uma floresta de domínios
de uma empresa. Este servidor ocupa o topo da hierarquia de autoridades
certificadoras. Normalmente não é utilizado para emitir certificados para usuários ou
computadores, mas sim para autoridades certificadores corporativas subordinadas. Os
certificados para usuários e computadores são emitidos pelas autoridades
subordinadas. Com isso você pode criar uma hierarquia de autoridades certificadoras,
de tal maneira que a emissão de certificados seja efetuada por um servidor do próprio
domínio do usuário. Outro detalhe importante é que a autoridade certificadora root é
responsável por assinar o seu próprio certificado (afinal não há nenhuma autoridade
http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 10/11
24/1/2014 Julio Battisti

acima dela). Isso é que caracteriza esta autoridade como uma autoridade certificadora
root.

2. Enterprise subordinate CA – Autoridade certificadora Corporativa

subordinada: Para instalar uma autoridade certificadora corporativa subordinada, você
deve ter acesso ao certificado da autoridade certificadora corporativa root. O uso deste
certificado é que liga a autoridade certificadora que está sendo instalada, como um
autoridade subordinada a autoridade certificadora root, formando uma hierarquia de
entidades certificadoras. Este tipo de autoridade pode emitir certificados para usuários e
computadores do Active Directory ou para outras autoridades certificadores
subordinadas de níveis mais baixo, aumentando desta maneira, o número de níveis da
hierarquia de autoridades certificadoras.

3. Stand-alone root CA – Autoridade certificadora autônoma root: Este tipo

de autoridade certificadora não depende do Active Directory. Pode ser utilizado, por
exemplo, para emitir certificados para parceiros de negócio e prestadores de serviço,
que precisam de certificados digitais para acessar determinadas áreas da Intranet ou da
Extranet da empresa. Uma vantagem adicional é que um servidor configurado como
autoridade certificadora autônoma root, pode ser desconectado da rede, como uma
garantia adicional de segurança. Este tipo de autoridade certificadora também é
responsável por emitir os certificados de registro das autoridades certificadoras
autônomas subordinadas.

4. Stand-alone subordinate CA - Autoridade Certificadora Autônoma

Subordinada: Este tipo de autoridade certificadora está subordinada a uma autoridade
certificadora autônoma root. O processo normalmente é o mesmo utilizado para o
caso das autoridades certificadoras corporativas, ou seja, a autoridade certificadora
autônoma root não é utilizada para emissão de certificados para usuários e
computadores, mas sim para a emissão de certificados para as autoridades
certificadoras autônomas subordinadas. As autoridades certificadoras autônomas
subordinadas é que são responsáveis pela emissão dos certificados para usuários e
computadores.

Conclusão

Nesta parte do tutorial fiz uma breve apresentação sobre PKI, Certificados Digitais e
Autoridades Certificadores. Você também aprendeu sobre a criptografia baseada no uso
de um par de chaves: pública e privada e como utilizar o Microsoft Certificate Services
para criar uma autoridade certificadora na própria rede da empresa.

http://www.juliobattisti.com.br/artigos/windows/tcpip_p19.asp 11/11