Pré-Requisitos: Conhecimento básico de redes e de Internet.
Metodologia: PKI, Certificados e uso de Certificate Services.
Técnica: Teoria e exemplos práticos, passo-a-passo.

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 são facilitam a vida de fraudadores e por aí vai.

Ao longo deste livro você aprendeu 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 das redes 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), 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 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. 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 cartão de crédito, ou quando você faz transações bancárias usando o site do seu Banco. Aqui 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 envia-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 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. 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. 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 (este é o papel do Certificate Services, ou seja, emitir, publicar 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 envia-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 de criptografia 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. 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 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 pública.

Um certificado de chave pública, geralmente chamado simplesmente 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.

Certificados podem ser emitidos para uma série de funções, 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 Server 2003 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). 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 Server 2003 (e também com o Windows 2000 Server), está disponível o 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, descrito brevemente no Capítulo 5. 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 garantir a 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), que pode ser 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 Server 2003 um servidor com o Microsoft Certificate Service) 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 – Certifcate 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 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 um terceiro remoto, 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. 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 Server 2003 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 Server 2003 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 Server 2003 (ou no Windows 2000 Server), o administrador também pode utilizar uma CA externa. Porém, com o uso do 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 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. 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 publicando uma lista de certificados revogados 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. Clientes podem usar as páginas da 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 ou do Windows Server 2003, 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 organização esteja usando Active Directory, a confiança nas autoridades de certificação da organização será tipicamente estabelecida automaticamente, baseado 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.

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, às vezes chamada de autoridade raiz, é 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 medida indicada é criar a entidade certificadora raiz da empresa, no mesmo servidor configurado como Schema Máster do domínio e proteger o acesso físico e lógico deste servidor, conforme descrito no Capítulo 6, sobre planejamento.

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 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 os Serviços de certificados para criar uma autoridade de certificação corporativa. Autoridades de certificação corporativas podem emitir certificados para finalidades 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/exigências:

• Uma autoridade de certificação corporativa exige o Active Directory.
• Quando você instala uma autoridade de certificação raiz corporativa, ela é automaticamente adicionada ao armazenamento de certificados das Autoridades de certificação raiz confiáveis, 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 raiz corporativa.
• 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.
• 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.

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

Dica: Se você está se preparando para o MCSE 2000 ou para o MCSE 2003, principalmente para o Exame 70-216, 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 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 e 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.

Muito bem, de teoria já está mais do que suficiente. Em seguida você aprenderá as ações práticas relacionadas com autoridades certificadoras e com a administração de certificados.

Instalando uma autoridade certificadora corporativa root.

Neste ítem você aprenderá a instalar o Microsoft Certificate Services em um controlador de domínio. Você irá criar uma autoridade certificadora corporativa root.

Nota: Após instalar o Certificate Services não será mais possível alterar o nome do servidor, uma vez que este nome é utilizado para a geração dos certificados.

Instalando o Certificate Services: Para instalar o Certificate Services siga os passos indicados a seguir:

1.         Faça o logon como administrador ou com uma conta com permissão de administrador.
2.         Abra o Painel de Controle: Start -> Control Panel (Iniciar -> Painel de Controle).
3.         Dê um clique duplo na opção Add or remove programs (Adicionar ou remover progrmas).
4.         Será exibida a janela Add or remove programs (Adicionar ou remover progrmas). Nas opções do lado esquerdo da janela, dê um clique na opção Add/Remove Windows Components (Adicionar ou Remover Componentes do Windows)
5.         Será aberto o assistente de componentes do Windows.
6.         Localize a opção Certificate Services e dê um clique para marcá-la, conforme indicado na Figura 20.34.

Figura 20.34 Instalando o Certificate Services.

7.         Ao clicar na opção Certificate Services será exibida uma mensagem, informando que o nome do servidor e o domínio ao qual ele pertence não poderão ser alterados após a instalação do Certificate Services, pois as informações sobre a autoridade certificadora que está sendo criada, dependem destas informações. Se uma destas informações forem alteradas, os certificados emitidos por esta autoridade certificadora, deixarão de ter validade. Clique em Yes para fechar a janela de aviso.
8.         Você estará de volta à janela de componentes, com a opção Certificate Services já selecionada.
9.         Clique em Next (Avançar), para iniciar a instalação do Certificate Services.
10.       Nesta etapa do assistente você deve informar o tipo de CA que está sendo criada. Marque a opção Enterprise root CA (Autoridade certificadora corporativa root) e marque também a opção Use custom settings to generate the key pair and CA certificate (Use configurações personalizadas para gerar o par de chaves e o certificado para a autoridade certificadora), conforme indicado na Figura 20.35:

Figura 20.35 Selecionando o tipo de CA que será criado.

11.       Clique em Next (Avançar), para seguir para a próxima etapa do assistente.
12.       Nesta etapa você define as configurações para a geração do para de chaves para a autoridade certificadora. Você pode escolher o provedor de criptografia – CSP (por padrão vem selecionada a opção Microsoft Strong Cryptographic Provider. Você também pode selecionar o algoritmo de hash. Os algoritmos MD4 e MD5 são bastante conhecidos, sempre que possível evite utilizar estes algoritmos. Você também pode utilizar uma chave já existente (por exemplo, gerada por uma autoridade certificadora externa) e o tamanho da chave, em bytes. Defina as opções desejadas, conforme exemplo da Figura 20.36:

Figura 20.36 Opções para a geração do par de chaves.

13.       Clique em Next (Avançar), para seguir para a próxima etapa do assistente.
14.       Nesta etapa você deve informar o nome com o qual a autoridade certificadora será registrada no Active Directory e o prazo de validade do certificado que, por padrão, é cinco anos. Defina as opções desejadas, conforme exemplo da Figura 20.37:

Figura 20.37 Definindo o nome e o prazo de validade.

15.       Clique em Next (Avançar), para seguir para a próxima etapa do assistente.
16.       Nesta etapa você define a pasta onde será armazenada a base de dados de certificados e o log de transações, por padrão é sugerida a pasta C:\%windi%\system32\CertLog para o banco de dados dos certificados e também para o logo de transações. Vamos aceitar as configurações padrão.
17.       Clique em Next (Avançar), para seguir para a próxima etapa do assistente.
18.       Será iniciada a instalação do Certificate Services. Durante o processo de instalação pode ser exibida uma mensagem solicitando que você insira o CD do Windows Server 2003. Se esta mensagem for exibida, insira o CD no drive e clique em OK para fechar a mensagem de aviso.

Nota: Se o IIS ainda não estiver instalado no servidor, será exibida uma mensagem de aviso, informando que a emissão de certificados não estará disponível até que o IIS seja instalado, conforme indicado na Figura 20.38. Se esta mensagem for exibida clique em OK para fecha-la e lembre-se de instalar o IIS, antes que você possa emitir certificados. Para detalhes sobre a instalação do IIS, consulte o Capítulo 23.

Figura 20.38 Aviso que é emitido quando o IIS não está instalado.

19.       A instalação será concluída e a etapa final do assistente de instalação será exibida. Clique em Finish (Concluir) para encerrar o assistente de instalação do Certificate Services.

Muito bem, uma vez que foi instalada uma autoridade certificadora, você já está em condições de emitir e revogar certificados. Na prática, na rede da empresa, primeiro você irá instalar todos os servidores que atuarão como CAs. Conforme descrito anteriormente, é comum instalar o CA root (corporativo ou autônomo) e depois instalar um ou mais servidores como autoridades certificadoras subordinadas. O CA root emite certificados para as autoridades certificadoras subordinadas, as quais, por sua vez, emitem certificados para usuários  computadores. No próximo tópico você aprenderá a emitir e revogar certificados, usando o autoridade certificadora corporativa root, instalada no exemplo deste item.

Emitindo e revogando certificados.

Para que uma CA possa emitir um certificado, uma requisição tem que ser feita. Uma requisição pode ser feita por um usuário, por um computador ou por um serviço, como por exemplo uma CA subordinada, solicitando um certificado para a CA pai, que está um nível acima na hierarquia. Em determinadas situações a requisição pode acontecer automaticamente, como por exemplo quando o usuário faz o logon no domínio usando um smart card. Como parte do processo de logon usando smart card, uma requisição de certificado é enviada para a autoridade certificadora.

Um usuário pode solicitar um certificado a qualquer momento. Para isso ele deve usar o consolo Certificates. Quando você instala o Certificate Services, não é criado, automaticamente, um atalho para o console Certificates (na opção Administrative Tools). A seguir mostrarei como adicionar este Snap-in e utilizá-lo para requisitar um certificado para um usuário do Active Directory.
Exemplo: Para acessar o console Certificates e requisitar um certificado, siga os passos indicados a seguir:

1.         Faça o logon com uma conta com permissão de Administrador.
2.         Selecione o comando Start -> Run (Iniciar -> Executar).
3.         Na janela que surge, no campo Abrir, digite mmc e dê um clique em OK.
4.         Será aberto o MMC sem nenhum Snap-In Carregado.
5.         Selecione o comando  Arquivo -> File -> Add/remove snap-in... (Adicionar/remover snap-in ..). Será exibida a janela Add/remove snap-in. Observe que não existe nenhum snap-in adicionado e a lista está vazia.
6.         Nesta janela dê um clique no botão Add... (Adicionar...).
7.         Será exibida a janela Add Standalone Snap-ins (Adicionar snap-in autônomo). Nesta janela é exibida uma listagem com todos os snap-ins disponíveis, isto é, instalados no computador.
8.         Localize na listagem o seguinte snap-in: Certificates (Certificados), conforme indicado na Figura 6.4 e dê um clique sobre ele para selecioná-lo.

Figura 20.39 Adicionando o Snap-in Certificates.

9.         Dê um clique no botão Add (Adicionar). Será exibida a janela onde você deve informar se o snap-in que está sendo adicionado irá gerenciar o certificado para a minha conta de usuário (My user account), minha conta de serviço (My service account) ou a conta de computador (My computer account), conforme indicado na Figura 20.40:

Figura 20.40 Selecionando o certificado que será gerenciado.

10.       Por padrão vem selecionada a opção My user account. Aceite a opção padrão e dê um clique no botão Finish (Concluir).
11.       Você estará de volta a janela Adicionar snap-in autônomo. Caso você queira será possível adicionar outros snap-ins. Como não será adicionado mais nenhum snap-in, dê um clique no botão Close (Fechar).
12.       Você estará de volta à janela Add/Remove Snap-in (Adicionar / remover snap-in).  Observe que o snap-in Certificates – Current user, já aparece na listagem.
13.       Dê um clique em OK para fechar esta janela.
14.       Você estará de volta ao MMC, agora com o snap-in Certificates já carregado, conforme indicado na Figura 20.41:

Figura 20.41 O console Certificates.

15.       Salve este console com o nome de Console Certificates. Para salvar o console é só executar o comando File -> Save (Arquivo -> Salvar) e informar a pasta onde o console será salvo e o nome do console. Conforme descrito no Capítulo 7, o console é salvo com a extensão .msc.
16.       Agora você utilizará o assistente para requisição de certificados.
17.       Clique no sinal de + ao lado da opção Certificates – Current User, para exibir as opções disponíveis.
18.       Nas diversas opções que são exibidas,clique com o botão direito do mouse na opção Personal (Pessoal) e, no menu de opções que é exibido, clique em All Tasks -> Request New Certificate... (Todas as tarefas -> Requisitar novo certificado...).
19.       Será aberto o assistente para requisição de novo certificado.
20.       A primeira tela do assistente é apenas informativa. Clique em Next (Avançar), para seguir para a próxima etapa do assistente.
21.       Nesta segunda etapa você deve marcar o tipo de certificado que será requisitado: Administrador (Administrator), Básico de EFS (Basic EFS), Agente de recuperação do EFS (EFS Recovery Agent) ou de Usuário (User). Para detalhes sobre o agente de recuperação do EFS, consulte o Capítulo 11. Vamos selecionar um novo certificado de Administrador e marcar para que sejam exibidas as opções avançadas, nas próximas etapas, conforme indicado na Figura 20.

Figura 20.42 Solicitando um certificado de Administrador.

22.       Clique em Next (Avançar), para seguir para a próxima etapa do assistente.
23.       Nesta etapa você pode especificar o tamanho da chave, o provedor de criptografia, se a chave poderá ser exportada ou não e se deve ser habilitado ou não a proteção “forte” para a chave privada. Selecione as opções desejadas e clique em Next (Avançar), para seguir para a próxima etapa do assistente de requisição de certificado.
24.       Nesta etapa você informa para qual autoridade certificadora (CA) será enviada a requisição. Você pode utilizar o botão Browse... (Procurar...), para selecionar uma das autoridades certificadoras disponíveis, conforme exemplo da Figura 20.43:

Figura 20.43 Selecionando a autoridade certificadora.

25.       Selecione a autoridade certificadora a ser utilizada e clique em Next (Avançar), para seguir para a próxima etapa do assistente.
26.       Nesta etapa você deve digitar um nome de identificação para o certificado (Friendly name) e uma descrição (Description). Preencha estes campos e clique em Next (Avançar), para seguir para a próxima etapa do assistente.
27.       Será exibida a tela final do assistente. Você pode utilizar o botão Back (Voltar) para voltar as etapas anteriores e fazer alterações. Clique em Finish (Concluir), para enviar a requisição de certificado, para a autoridade certificadora selecionada na etapa 24.
28.       Será exibida uma mensagem informando que a requisição foi enviada com sucesso. Clique em OK para fechar esta mensagem.

Pronto, a solicitação de certificado foi enviada. Como foi solicitado um certificado para uma conta do domínio (a conta de Administrador), a requisição será enviada para a autoridade certificadora selecionada e será aprovada. Você pode conferir se a requisição já foi aprovada, clicando na opção Personal -> Certificates, do console Certificates. Observe que são exibidos dois certificados, o certificado original e o que foi requisitado no nosso exemplo, para o qual dei o nome de ExemploRequisição, conforme indicado na Figura 20.44:

Figura 20.44 O certificado ExemploRequisição.

Utilizando a o seu navegador para para gerenciar certificados.

Quando o Certificate Services é instalado, se o IIS já estiver instalado, é criada uma pasta virtual (você aprenderá sobre pastas virtuais no Capítulo 23) com uma página para gerenciamento de certificados. Se o IIS não estiver instalado e você instalar o IIS após a instalação do Certificate Services, você deve executar o seguinte comando, para que a pasta virtual seja criada e a página de gerenciamento de certificados esteja disponível:
certutil -vroot

No exemplo a seguir mostro como usar a página de gerenciamento de certificados.

Exemplo: Usando o navegador para gerenciar certificados:

1.         Faça o logon como Administrador ou com uma conta com permissão de administrador.
2.         Abra o Internet Explorer e acesse o seguinte endereço: http://localhost/certsrv.
3.         Será exibida a página para gerenciamento de certificados, com as opções indicadas na Figura 20.45:

Figura 20.45 A página Web para gerenciamento de certificados.

4.         Por exemplo, clique no link Request a certificate (Solicitar um certificado).
5.         Será aberta uma nova página. Clique na opção User Certificate (Certificado de usuário).
6.         Na pagina que é carregada clique em More Options >> (Mais opções >>).
7.         Nas opções que são exibidas clique em “use the Advanced Certificate Request form” (Formulário Avançado de solicitação de certificado). Será exibido um formulário com as diversas opções de configuração para o certificado. São exatamente as informações que você teve que fornecer usando o assistente, conforme pode ser conferido na Figura 20.46:

Figura 20.46 O formulário com as opções completas.

8.         Clique no botão Submit > (Enviar >).
9.         A requisição será enviada, aprovada pela autoridade certificadora e o certificado estará disponível para ser utilizado. É exibida uma página com o link Install this certificate (Instalar este certificado).
10.       Pronto, o certificado é instalado e está disponível para ser utilizado pelo usuário. A utilização da página Web é de grande ajuda, para que os usuários possam enviar suas solicitações de novos certificados, diretamente de suas máquinas, sempre que necessário.
11.       Feche o Internet Explorer.

Verificando a lista de certificados pendentes.

Pode acontecer de uma solicitação de certificado ficar pendente na autoridade certificadora  e depender de uma ação do administrador, para aprovar ou rejeitar a solicitação de certificado. Você pode gerenciar a lista de pendências de duas maneiras: Usando o console Certificate Authority (Autoridade Certificadora), cujo atalho está disponível no menu Adminstrative Tools (Ferramentas administrativas), ou usando a página de administração de certificados, no endereço: http://NomeDoServidor/certserv

Exemplo: Para verificar a lista de pendências usando o console Certificate Authority, siga os passos indicados a seguir:

1.         Faça o logon com uma conta com permissão de administrador.
2.         Abra o console Certificate Authority: Start -> Administrative Tools -> Certificate Authority (Inicar -> Ferramentas Administrativas -> Autoridade Certificadora).
3.         O console será aberto com o nome da autoridade certificadora sendo exibida.
4.         Clique no sinal de + ao lado do nome da autoridade certificadora, para exibir as opções disponíveis.
5.         Nas opções que são exibidas clique em Pending Requests (Solicitações Pendentes), conforme indicado na Figura 20.47:

Figura 20.47 Gerenciando certificados pendentes.

6.         As requisições pendentes serão exibidas no painel da direita.
7.         Para rejeitar uma solicitação de certificado, clique na respectiva solicitação com o botão direito do mouse e, no menu de opções que é exibido, clique em All Tasks -> Deny (Todas as tarefas -> Negar).
8.         Para aceitar a solicitação e efetivamente emitir o certificado, clique na respectiva solicitação com o botão direito do mouse e, no menu de opções que é exibido, clique em All Tasks -> Issue (Todas as tarefas -> Emitir).
9.         Repita as operações de Negar ou Emitir nos demais certificados pendentes.
10.       Feche o console Certificate Authority (Autoridade Certificadora).

Mapeando certificados com contas do Active Directory.

É possível fazer o mapeamento entre o certificado emitido para um usuário e a respectiva conta do usuário. Com isso, aplicações podem utilizar a chave pública contida no certificado do usuário, para fazer a autenticação do usuário. Com este mapeamento, ao ser autenticado usando o certificado, é como se o usuário tivesse fornecido o nome de usuário e respectiva senha.

O modelo do Active Directory, na qual existe uma base de usuários e demais informações, replicada em todos os DCs do domínio é eficiente e adequada para a maioria das empresas. Porém para redes muito grandes, ou sites com um número elevado de usuários (milhões), fazer a autenticação tradicional através de links de WAN pode trazer problemas sérios de desempenho.

Com o uso de certificados estes problemas podem ser minimizados. Os certificados podem ser criados e enviados para os usuários finais. Com isso, o usuário utiliza o seu certificado digital para fazer a autenticação nos sistemas habilitados a utilizar certificados digitais. Isso evita que o nome do usuário e senha tenham que ser enviados através da rede, para validação em uma base centralizada de usuários, o que, repito, quando lidamos com um grande número de usuários, pode trazer problemas de desempenho. Por outro lado, existem sistemas operacionais e aplicativos que não estão habilitados para aceitar certificados digitais. A solução para esta questão é criar um mapeamento entre a conta do usuário e o respectivo certificado digital. Com este mapeamento, os sistemas habilitados a utilizar certificados, utilizarão o certificado do usuário para fazer a autenticação, já os sistemas não habilitados a utilizar certificados, usarão o método tradicional de autenticação, onde o usuário informa o nome de logon e senha.

Com este modelo, quando o usuário possui um certificado, o sistema irá identificar qual a conta que está associada com o certificado e fará o logon usando esta conta. Não confundir esta funcionalidade com o logon usando Smart card. O Windows Server 2003 Standard Edition, Enterprise Edition e Datacenter Edition dão suporte ao logon usando Smart card, porém neste caso, o mapeamento com a conta do usuário é automático.

Tipos de mapeamentos:

Na maioria dos  casos, o certificado é mapeado com uma conta de usuários em uma das seguintes maneiras: um certificado para uma conta de usuário (mapeamento um-para-um) ou múltiplos certificados são mapeados para um única conta de usuário (mapeamento muitos-para-um).

Mapeamento do nome principal do usuário:

O mapeamento do nome principal do usuário é um caso especial de mapeamento um-para-um. Para empregar o mapeamento do nome principal do usuário, use o Active Directory. Com o mapeamento do nome principal do usuário, o nome principal do usuário é usado para localizar a conta do usuário no Active Directory e para efetuar logon na rede ou no servidor. O nome principal do usuário se parece muito com um nome de correio eletrônico e é exclusivo dentro de um domínio do Windows 2000 ou do Windows Server 2003 . As autoridades de certificação corporativas colocam o nome principal de usuário do proprietário do certificado em cada certificado. Portanto, para acessar um servidor IIS seguro ou para efetuar logon no Windows Server 2003 com um cartão inteligente, o mapeamento de nomes de usuários para contas é automático nesses certificados.

Mapeamento um-para-um:

O mapeamento um-para-um mapeia um único certificado de usuário para uma única conta de usuário do Windows Server 2003. Por exemplo, imagine que você deseje fornecer uma página da Web para seus empregados, para que eles possam visualizar e modificar suas deduções e gratificações, administrar o plano de saúde e várias outras opções de benefícios. Essa página deve funcionar na Internet e deve ser segura. Como solução, você decide usar o Windows Server 2003, certificados e mapeamento de certificados. Você pode emitir certificados para cada um dos empregados a partir de seu próprio serviço de certificados ou pode fazer com que os empregados obtenham certificados de uma autoridade de certificação aprovada por sua empresa. Você poderá então pegar esses certificados de usuários e mapeá-los para a conta de usuário do empregado no Windows Server 2003. Isso permite que um usuário se conecte à página da Web usando os protocolos SSL (camada de soquetes de segurança) ou TLS (segurança da camada de transporte) a partir de qualquer lugar, fornecendo seu certificado de cliente. O usuário efetua então logon em sua própria conta de usuário e os controles de acesso normais do Windows Server 2003 podem ser aplicados.

Mapeamento muitos-para-um:

O mapeamento muitos-para-um mapeia muitos certificados para uma única conta de usuário. Por exemplo, você tem uma parceria com uma agência que fornece empregados temporários para as oportunidades de trabalho surgidas em sua empresa. Você gostaria que o pessoal da agência pudesse ver as páginas da Web que descrevem as oportunidades de trabalho atuais que só os funcionários da empresa podem ver. A agência tem sua própria autoridade de certificação, que ela usa para emitir certificados para os empregados. Depois de instalar o certificado raiz da autoridade de certificação da agência como uma raiz confiável no CA root da sua rede, você pode definir uma regra que mapeie todos os certificados emitidos por essa autoridade de certificação para uma única conta do Windows Server 2003. Você pode então definir os direitos de acesso da conta, de tal forma que essa conta possa acessar aquela página da Web.

A seguir apresento os passos práticos para fazer o mapeamento entre certificados e contas de usuários.

Exemplo: Para fazer o mapeamento entre uma conta de usuário e um certificado, siga os passos indicados a seguir:

1.         Faça o logon como administrador ou com uma conta com permissão de administrador.
2.         Abra o console Active Directory Users and Computers: Start -> Administrative Tools -> Active Directory Users and Computers (Iniciar -> Ferramentas Administrativas -> Usuários e Computadores do Active Directory).
3.         Selecione o commando View -> Advanced Features (Exibir -> Recursos avançados).
4.         Acesse a opção onde está a conta de usuário a ser mapeada com o um certificado.
5.         Clique na conta para seleciona-la.
6.         Clique com o botão direito do mouse na conta e, no menu de opções que é exibido clique em Name Mappings... (Mapeamentos de nome...).
7.         Será exibida a janela Security Identify Mapping (Mapeamento de Identidade de Segurança), com a guia X.509 Certificate (Certificado X.509) já selecionada, conforme indicado na Figura

Figura 20.48 A guia X.509 Certificate.

8.         Clique am Add... (Adicionar...).
9.         Será aberta uma janela para que você informe o artigo .cer, no qual está o certificado a ser associado com a conta do usuário. Localize o arquivo com o certificado e dê um clique para marca-lo. Em seguida clique em Open (Abrir). Será aberta uma janela com informações básicas sobre o certificado selecionado. Clique em OK para fechar esta janela.
10.       Você estará de volta à janela Security Identify Mapping (Mapeamento de Identidade de Segurança), com o certificado selecionado já sendo listado.
11.       Clique em OK e pronto, o certificado será associado com a conta. Para associar mais de um certificado com a mesma conta (mapeamento muitos-para-um), basta repetir os passos de 5 a 11.

Verificando as informações contidas em um certificado.

Você pode exibir as informações contidas em um certificado. Para exibir as informações contidas em um certificado, siga os passos indicados a seguir:

1.         Faça o logon com uma conta com permissão de administrador.
2.         Abra o console Certificate Authority: Start -> Administrative Tools -> Certificate Authority (Inicar -> Ferramentas Administrativas -> Autoridade Certificadora).
3.         O console será aberto com o nome da autoridade certificadora sendo exibida.
4.         Clique no sinal de + ao lado do nome da autoridade certificadora, para exibir as opções disponíveis.
5.         Nas opções que são exibidas clique em Issued Certificates (Certificados Emitidos). No painel da direita será exibida a lista de certificados emitidos pela autoridade certificadora.
6.         Dê um clique duplo no certificado para o qual você quer exibir as informações. Na janela que é aberta dê um clique na guia Details (Detalhes). Será exibida a lista com os valores dos campos do certificado, conforme indicado na Figura 20.

Figura 20.49 Exibindo informações sobre um certificado.

7.         Clique em OK para fechar a janela de informações.
8.         Feche o console Certificate Authority (Autoridade Certificadora).

Revogando certificados e gerenciando a lista de certificados revogados.

O administrador pode revogar um certificado sempre que necessário. A autoridade certificadora mantém uma lista de certificados revogados (CRL – Certificate Revocation List). Quando um certificado é apresentado para fazer a autenticação em um sistema, primeiro o sistema consulta a lista de certificados revogados, para saber se o certificado que está sendo apresentado não faz parte da lista de certificados revogados. Se fizer, a autenticação não será efetuada.

Para revogar certificados e exibir a lista de certificados revogados, siga os passos indicados a seguir:

1.         Faça o logon com uma conta com permissão de administrador.
2.         Abra o console Certificate Authority: Start -> Administrative Tools -> Certificate Authority (Inicar -> Ferramentas Administrativas -> Autoridade Certificadora).
3.         O console será aberto com o nome da autoridade certificadora sendo exibida.
4.         Clique no sinal de + ao lado do nome da autoridade certificadora, para exibir as opções disponíveis.
5.         Nas opções que são exibidas clique em Issued Certificates (Certificados Emitidos). No painel da direita será exibida a lista de certificados emitidos pela autoridade certificadora.
6.         Para revogar um certificado clique com o botão direito do mouse no certificado a ser revogado e, no menu de opções que é exibido, clique em All Tasks -> Revoke Certificate (Todas as tarefas -> Revogar certificado).
7.         Será exibida uma janela para que você informe o motivo pelo qual o certificado está sendo revogado, conforme indicado na Figura 20.50:

Figura 20.50 Informando o motivo para revogação do certificado.

8.         Selecione o motivo e clique em Yes, para revogar o certificado.
9.         O certificado deixará de ser exibido na opção Issued Certificares (Certificados emitidos) e passará a ser exibida na opção Revoked Certificates (Certificados Revogados).
10.       Você pode desfazer a revogação de um certificado. Para isso clique na opção Revoked Certificates (Certificados Revogados). No painel da direita será exibida a lista de certificados revogados. Clique no certificado cuja revogação será desfeita, com o botão direito do mouse e, no menu de opções que é exibido, clique em All Tasks -> Unrevoke Certificate (Todas as tarefas -> Desfazer revogação do certificado).
11.       Pronto, o certificado passa a estar ativo novamente e volta a ser exibido na listagem da opção Issued Certificates (Certificados Revogados).

Renovando o certificado da autoridade certificadora.

Quando você cria uma autoridade certificadora, é emitido um certificado para esta CA. Este certificado, por padrão, tem uma validade de cinco anos. Antes de vencer este período o administrador deve renovar o certificado.

Para renovar o certificado da autoridade certificadora, siga os passos indicados a seguir:

1.         Faça o logon com uma conta com permissão de administrador.
2.         Abra o console Certificate Authority: Start -> Administrative Tools -> Certificate Authority (Inicar -> Ferramentas Administrativas -> Autoridade Certificadora).
3.         O console será aberto com o nome da autoridade certificadora sendo exibida.
4.         Clique com o botão direito do mouse nome da autoridade certificadora e, no menu de opções que é exibido clique em All Tasks -> Renew CA Certificate... (Todas as tarefas -> Renovar o certificado da CA...).
5.         Será exibida uma janela informando que o Certificate Services tem que ser parado para que a renovação possa ser efetuada. Clique em Yes para continuar com a renovação.
6.         Será exibida uma janela informando que, além de renovar o certificado, você pode gerar uma nova chave de assinatura. É indicado que você gere uma nova chave. Para tal selecione a opção Yes (Sim), conforme indicado na Figura 20.51 e clique em OK.

Figura 20.51 Gerando uma nova chave de assinatura.

7.         O certificado é renovado e o Certificate Services é inicializado.

Fazendo o backup e o restore da base de dados da autoridade certificadora.

Uma medida de fundamental importância é fazer o backup periódico da base de dados da autoridade certificadora.

Para fazer o backup/restore da base de dados da autoridade certificadora, siga os passos indicados a seguir:

1.         Faça o logon com uma conta com permissão de administrador.
2.         Abra o console Certificate Authority: Start -> Administrative Tools -> Certificate Authority (Inicar -> Ferramentas Administrativas -> Autoridade Certificadora).
3.         O console será aberto com o nome da autoridade certificadora sendo exibida.
4.         Para fazer o backup da base de dados clique com o botão direito do mouse nome da autoridade certificadora e, no menu de opções que é exibido clique em All Tasks -> Backup CA... (Todas as tarefas -> Backup da CA...) e siga os passos do assistente.
5.         Para fazer o restore da base de dados clique com o botão direito do mouse nome da autoridade certificadora e, no menu de opções que é exibido clique em All Tasks -> Restore CA... (Todas as tarefas -> Restore da CA...) e siga os passos do assistente.