Utilizando Certificados Digitais

Marcelo Sincic
Microsoft MCT-MCITP-MCPD-MCTS-MCDBA-MCSA
Outubro 2009
Tecnologias

Neste documento utilizamos o Windows Server 2008 com as features de Web Server e Certificate Authority.
Sumário

Instalar uma certificadora digital para certificar o nosso servidor web e os usuários com o objetivo de utilizar certificados digitais para criptografia e autenticidade, tanto na comunicação quanto na autenticação dos clientes.

Conteúdo

Introdução
Argumentos para utilizarmos certificados
Como funciona a estrutura PKI
Parte 1: Configurando um servidor para utilizar certificados do cliente na autenticação
Parte 2: Emitindo e certificando o IIS
Parte 3: Emitindo e certificando o usuário
Dicas
Conclusão
Referências + Tópicos Relacionados
Sobre o Autor

Introdução

Atualmente todos estão preocupados com a segurança e autenticidade de documentos e relacionamentos eletrônicos, uma vez que muitos usuários utilizam a internet para enviar documentos, consultar processos e realizar transações financeiras, fiscais e, recentemente, legais. Cada vez mais notamos que pedir o nome do usuário e uma senha não é a forma ideal de garantirmos a autenticidade, e intuições como bancos utilizam quatro ou cinco métodos de validações adicionais alem do clássico “user-pass”.

Neste ponto é que surgem as chaves criptográficas, armazenadas em certificados digitais, que garantem a identidade de uma empresa, pessoa física ou um site na internet. Para termos uma idéia da importância e necessidade desta tecnologia, desde o ano passado algumas transações no site da Receita Federal só podem ser feitas por quem tem um certificado, bem como o FINEP para universitários que queiram financiamento, sistemas de exportação baseados no SISCOMEX, e muitos outros.

O certificado é um arquivo de pouco mais de 1Kb que contem uma chave criptográfica e dados de seu proprietário. No caso do programa ICP-Brasil, os dados gravados são Nome, CPF, RG, etc.

O programa ICP-Brasil (Infraestrutura de Chaves Publicas, sigla em português para a tecnologia PKI, ou, Public Key Infrastructure) juntamente com seus agregados de identificação, o e-CPF e o e-CNPJ, que respectivamente identificam uma pessoa física e uma jurídica. Uma observação importante: a tecnologia real se chama PKI, o ICP-Brasil é uma série de medidas legais, técnicas e normas que possibilitaram o surgimento de versões virtuais de nossos CPFs e CNPJs.

Por exemplo, para ter um e-CPF ou um e-CNPJ é necessário comparecer a um posto do SERASA com seus documentos, alem do pagamento e do pedido já efetuado na internet, para verificar os dados e deixar sua assinatura devidamente registrada. Só após a conferência dos documentos que enviam o documento eletrônico.

A utilização deste método de autenticação e segurança ainda é baixa, em primeiro lugar porque o custo é relativamente alto para o usuário final, que pode variar entre o modelo A1 que custa em torno de R$ 100,00 e chegando ao kit do modelo A3 em R$ 700,00. Outro problema é que os usuários em geral ainda não se deram conta do risco que existe no uso da internet sem o certificado nas duas pontas e as empresas ainda podem se esquivar de responsabilidades por utilizar múltiplos métodos de segurança.

Neste artigo veremos agora como se pode utilizar certificados digitais, sejam os emitidos pelo ICP-Brasil ou utilizando o modelo PKI já disponível no Windows Server desde a versão 2000. Também abordaremos como emitir certificados para nossos usuários sem que eles tenham o custo de comprar um.

É importante notar que neste artigo estaremos focando o Windows 2008, mas em meu site você poderá ler também o artigo baseado no Windows 2003, com as mesmas funcionalidades abordadas.

Argumentos para utilizarmos certificados

Para entender os tipos de certificados e o que está por trás de toda esta tecnologia PKI devemos, em primeiro lugar, abordar a questão do custo e tipo dos certificados. Quando falamos em tipos de certificados na verdade nos referimos a como chegaram até o cliente e como o cliente o usa fisicamente, e não o certificado em sí mesmo.

O certificado do modelo A1 consiste em um arquivo que contem duas chaves, uma pública e outra privada Já o modelo A3 é o conhecido “smartcard”, que agora bancos como Itaú e Bradesco passaram a distribuir aos seus clientes. A utilização dos cartões A3 tem seu custo mais elevado em razão do leitor que é necessário adquirir. Algumas empresas vendem o kit A3, como a Itautec, contendo o cartão, a mídia com o arquivo, o leitor de smartcard que é conectado na USB e uma visita técnica para instalação. Como o A1 é apenas distribuído com uma mídia simples, pode-se encontrá-lo ao preço de R$ 150,00 no site do SERASA, CertSign e outros. O A3 também pode ser comprado nos mesmos lugares ao preço médio de R$ 400,00. Mas neste caso a leitora não está incluída. Como em qualquer negociação é possível procurar a “concorrência”, já que os certificados são vendidos por diversas empresas alem destas citadas.

O segundo argumento para utilização dos certificados pessoais é que nós, usuários, ainda não nos demos conta do real perigo oferecido pela certificação como é utilizada atualmente. Para entendermos este risco veja a Figura 1, lado esquerdo. Podemos notar que o modelo tradicional, apenas o servidor da empresa possui a chave de autenticação (vide Nota 1), portanto ele é quem diz ser. Fazemos isto por utilizar uma chave criptográfica para montar um servidor SSL (https), que nada mais é do que ter certeza de que aquele servidor realmente pertence a sua empresa, por isso é chamado de “Digital Signature” (Assinatura Digital). Mas quem garante que “você” realmente é quem diz ser?

Figura 1 – Utilizações padrão de certificados

Nota 1 – Chaves Públicas e Privadas
A chave pública (Public Key) é aquela que apenas o emissor possui, enquanto a chave privada (Private Key) é trocada com todos os que acessam o site. Esse modelo é chamado de assimétrico, já que a utilização da chave pública para criptografar o faz com o algoritmo que apenas a privada consegue abrir, e vice-versa. Ou seja, com a chave publica lemos o que foi criptografado com a chave privada, mas não conseguimos alterar, uma vez que apenas a privada consegue abrir o que a pública criptografou, garantindo que o dono do certificado é ele mesmo, pois uma chave “falsificada” não conseguiria abrir a assinatura digital no documento ou no site.

Na figura 1 do lado direito notamos que com o certificado do usuário a recíproca passa a ser verdadeira, tanto o usuário quando o servidor são confiáveis e autênticos.

Anteriormente a única garantia que um banco ou uma empresa tem em relação à quem está logando em uma página privada ocorre através de identificadores, como por exemplo um número de agência e conta, para os sites de banco, ou então um endereço de email para demais sites.

Esses métodos eram facilmente burlados, por exemplo, alguém utilizando um trojan descobria o que você digitou e poderia utilizar esses dados para acessa a sua conta. Então começaram nos bancos os irritantes métodos físicos, cartão com códigos, letras que mudam de posição, teclado que se movimenta na tela, número de confirmação grafado no cartão e outros que muitas vezes nos fazem desistir da transação.

Como funciona a estrutura PKI

Então agora que já entendemos que certificados digitais só nos ajudam, como funciona a tecnologia PKI?

A Figura 2 demonstra como ele funciona e suas vantagens em uma aplicação corporativa, onde apenas quem possui um certificado emitido pela empresa consegue o acesso. Este processo é chamado de “não repúdio”.

Claro que aqui estamos apenas alistando um exemplo de aplicação, sendo que os certificados são emitidos pela própria empresa e não utilizando o modelo e-CPF/e-CNPJ que são emitidos pelo SERPRO, SERASA ou outra credenciada.

Figura 2 – Modelo básico com acesso utilizando certificados

Detalhando melhor os principais componentes PKI, podemos destacar 4 serviços principais:

CA (Autorizada de Certificação) que emite os certificados. As certificadoras são bem conhecidas empresas que mantém um banco de dados com os certificados emitidos, bem como o CRL atualizado. Nem sempre se utiliza a CA para emissão de certificados e sim um subordinado.

Subordinate CA (Autoridade de Certificação Subordinada) que também emite os certificados, mas utilizando uma “corrente” ligada a CA raiz. Este modelo é utilizado pela maior parte das certificadoras conhecidas, como a VeriSign, CertSign e outras. No Brasil, como exemplo, o SERASA emite certificados SSL que são subordinados a GlobalSign. O motivo é muito simples, as “certificadoras confiáveis” já estão pré-configuradas nos sistemas operacionais, como pode ser visto na figura 3. Esta lista é uma parte na encontrada no Internet Explorer ao entrar em “Opções-Conteudo-Certificados” e o SERASA não consta na lista, obviamente porque é uma empresa que não é conhecida fora do Brasil para ser incluída, por isso utilizar um secundário de outra já cadastrada.

Figura 3 - Internet Explorer 8

CRL (Certificate Revogation List) é um servidor mantido pela CA ou subordinada e que mantém uma lista dos certificados que foram revogados ou cancelados. Esta lista nos protege contra o mau uso ou desvio do certificado para outros fins. A Verisign a alguns anos atrás teve que noticiar que havia emitido dois certificados para a Microsoft quando na verdade os solicitantes utilizaram documentos falsos. A solução neste caso é revogar os certificados e publicá-lo na CRL.

Certificado Digital, por fim, é um arquivo que contem as chaves pública e privada. A chave privada só é conhecida do proprietário e da CA que a emitiu. A chave pública é conhecida por todos os que se comunicam com o proprietário da chave. O modelo de criptografia utilizado é assimétrico, o proprietário utiliza a chave privada para criptografar suas mensagens e a chave pública contém o algoritmo para descriptografar. O inverso na comunicação ocorre quando o destinatário envia para o proprietário utilizando a chave pública para criptografar, garantindo que apenas o proprietário conseguirá descriptografar, uma vez que ele é o único que tem a chave inversa, neste caso a privada. O certificado contém um importante dado dentro dele chamado de “subject”, onde consta os dados de quem é o proprietário da chave e outros dados que a certificadora queira incluir como mostra a figura 4.

Figura 4 - Subject do certificado

Parte 1: Configurando um servidor para utilizar certificados do cliente na autenticação

Agora que já temos um bom panorama do porque os certificados são importantes e como sua infraestrutura foi planejada vamos configurar o IIS para utilizar os certificados. Utilizaremos uma certificadora baseada no Windows 2008 para a emissão, já que para podermos fazer o processo de autenticação por certificados precisamos que o servidor IIS esteja com SSL habilitado. O meu servidor já está certificado e abordaremos como este processo foi feito adiante. Utilizarei neste exemplo um certificado próprio emitido pelo Windows 2008, mas o processo é o mesmo para o e-CPF/e-CNPF, apenas ao invés de utilizar um servidor próprio utilizaria um do ICP Brasil.

Talvez você se pergunte porque utilizar uma certificadora própria se o ICP-Brasil já existe para isso, mas lembre-se de que no inicio do artigo foi comentado que os certificados e-CPF/e-CNPJ são pagos, e com preços bastante elevados por sinal.

Nota
Lembre-se que Autoridade Certificadora (CA) é quem emite o certificado, arquiva e mantêm a lista de revogação (CRL). Se o CA é interna ou da internet como as mais conhecidas e do ICP-Brasil não faz diferença no uso de PKI e certificados digitais.

Outra questão é como fazer o mesmo processo em servidores, como o Apache, por exemplo. Qualquer servidor web permite o uso de certificados para SSL, mas obviamente não é tão simples quanto no IIS. Quanto a emissão de certificados, tocamos no calcanhar de aquiles, já que emissão de certificados no Linux é bem mais complexo do que no Windows Server, mas também pode ser feito. Contudo, não vamos abordar esse tema nesse artigo.

Voltando ao IIS, veja na Figura 5 que para utilizar a opção “Require client certificate” é necessário também ter o servidor certificado. Caso não possua o seu servidor com SSL poderá utilizar a opção “Accept client certificate” que não exige, apenas permite o uso de certificados pelo cliente, não garantindo assim um bom método de autenticação.

Figura 5 - Habilitando o uso de certificados no IIS

A Figura 6 demonstra o que acontece ao tentar acessar um servidor certificado e com obrigatoriedade de certificado pelo cliente. O erro “403.7” obviamente pode ser redirecionado para uma página de erro customizada que informe ao usuário que ele precisa comprar um certificado e a lista de onde isto pode ser feito, por exemplo.

Nota
Não tente tratar este erro por try-catch pois a aceitação e leitura do certificado é feita diretamente pelo IIS, e neste caso a aplicação nem é inicializada.

Figura 6 - Acesso proibido por falta de um certificado

Após instalar o certificado para o meu usuário, Figura 7, uma lista dos certificados que eu possuo na maquina é mostrada, permitindo que eu escolha qual utilizar. Esta lista só aparece caso o usuário solicite ou se existirem múltiplos certificados.

Figura 7 - Certificado sendo solicitado ao usuário

Parte 1.1: Utilizando os dados do certificado

O próximo passo é ler os dados do certificado para validar o usuário, e isto é mostrado na Figura 8, onde está listado o conteúdo do “subject” com os dados utilizados quando comprei o certificado. Para extrair estes dados foi utilizado o código da Listagem 1, que é extremamente simples.

Figura 8 - Acesso permitido e os dados do certificado exibidos

  <HTML>
       <BODY>
             <H1>Bem-vindo </H1>
             <%=Request.ClientCertificate.Subject%>
       </BODY>
</HTML>

Listagem 1. Código ASP para ler os dados do certificado

Vale lembrar que neste certificado o subject é o email do cliente, mas isto é configurável, portanto o subject de um e-CPF será o numero do documento.

Parte 2: Emitindo e certificando o IIS

A grande sacada é que o Windows Server desde a versão 2000 já possuem certificadoras !!!!

Portanto, esqueça o custo e a dificuldade, você mesmo pode criar a certificadora, certificar o seu site e seus usuários, precisando para isso ter apenas um servidor e o CD de instalação na mão.

Para instalar o serviço de certificação no seu Windows 2008 utilize o método normal de instalação de componentes: Server Manager -> Roles -> Add Roles...

Escolha na lista a opção “Certificate Authority”. Na tela de configuração do componente selecione “Standalone Certification Authoriry” e informe os dados de sua empresa, mas note que existe a opção para validade dos certificados. Se escolher a validade muito baixa seus usuários estarão sempre tendo que renová-lo. Por outro lado, certificados com tempo muito longo podem ter problemas de “vazamento” por parte do usuário. Utilize um período como 1 ou 2 anos que é o padrão utilizado hoje nos certificados comerciais.

Após a instalação o papel de certificados aparece na console, conforme a Figura 9.

Figura 9 - Roles CA instalada

 

Para certificar o IIS utilizando os seus próprios certificados o processo é o mesmo que utilizar um certificador comercial. Abra o gerenciador do IIS, abra propriedades do seu site no painel de ações (Figura 10), clique em “Create Certificate Request”.

Figura 10 - Configurando a segurança

Preencha agora os dados do seu site, conforme mostra a Figura 11

Importante
Na opção “Common Name” coloque o nome do seu domínio na internet, *.seudominio.com.br, pois se fizer diferente disto no momento em que seu site for aberto ocorrerá um erro informando que o certificado não pertence ao seu site.

Figura 11 - Resumo dos dados do certificado

Após completar os dados será gerado um arquivo texto com o conteúdo criptografado do que você informou, conforme a Figura 12.

Figura 12 - Arquivo gerado com os dados

O conteúdo deste arquivo será a sua chave privada, como mostra a Listagem 2.

-----BEGIN NEW CERTIFICATE REQUEST-----

MIIDUDCCArkCAQAwdTELMAkGA1UEBhMCQlIxCzAJBgNVBAgTAlNQMRIwEAYDVQQH

EwlHdWFydWxob3MxEDAOBgNVBAoTB0V4ZW1wbG8xEDAOBgNVBAsTB0V4ZW1wbG8x

ITAfBgNVBAMeGABtAHMAaQBuAGMAaQBjAF8AdwAyAGsAMzCBnzANBgkqhkiG9w0B

AQEFAAOBjQAwgYkCgYEAwcRAXg3lIfpu9NbN0vpgPw9eR1P3scccq79fwO2Xkc/X

rpZmxPzdsLnN0jwFfLLe7GotTnBotlLrsgipCevCs6wEM8gY0EJmdqxYqLuk783J

IXRoTuB5RbvdMUtBj/6wAVOaVAUJTeAvK9OMdqNzS9iCRr25XWpECjbWXor8IoUC

AwEAAaCCAZkwGgYKKwYBBAGCNw0CAzEMFgo1LjIuMzc5MC4yMHsGCisGAQQBgjcC

AQ4xbTBrMA4GA1UdDwEB/wQEAwIE8DBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3

DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwEwYD

VR0lBAwwCgYIKwYBBQUHAwEwgf0GCisGAQQBgjcNAgIxge4wgesCAQEeWgBNAGkA

YwByAG8AcwBvAGYAdAAgAFIAUwBBACAAUwBDAGgAYQBuAG4AZQBsACAAQwByAHkA

cAB0AG8AZwByAGEAcABoAGkAYwAgAFAAcgBvAHYAaQBkAGUAcgOBiQAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMA0GCSqGSIb3DQEBBQUA

A4GBAG3b+qC3ta8nYl6tD2Ens4El/qsvlMvn5QaI88w4zhSXmK4gnj3coIzAbUl8

MC0s4C/H9x1fJYhOfnore8FyUkTTv8SlobP7k3Y+eHI994OqUbeZuxTFme1j0O0A

EiCOmyFyuz9kUSCU/4lQ5I8ZhWbcW9ZSkyYWDiCjcpF+Gw/y

-----END NEW CERTIFICATE REQUEST----

Listagem 2. Arquivo certreq.txt

Por mais incrível que pareça neste emaranhado de letras e números estão gravados os dados que foram informados no IIS na tela de configuração.

O próximo passo é utilizar a página da certificadora para emitir o certificado para servidor. Utilize a url https://localhost/certsrv para acessar a certificadora como na Figura 13.

Figura 13 - Certificadora Windows 2008 baseada em web

Escolha a opção “Request a certificate” -> “Advanced certificate request” -> “Submit a certificate request by using a base-64-encoded …”. Na caixa de texto cole o conteúdo do arquivo texto ou então use o link para encontrar o arquivo certreq. No final receberá uma tela de confirmação de pedido encaminhado e avisa que é necessário o administrador liberar o seu certificado. Estes passos estão nas Figuras 14, 15 e 16.

Figura 14 - Escolha do tipo de certificado

Figura 15 - Opção por formulário ou envio de arquivo PKCS

Figura 16 - Formulario para pedido de certificado com PKCS

Esta liberação é feita na ferramenta “Active Directory Certificate Authority” nas ferramentas administrativas do certificador. Ao abrir vá à árvore “Pending Requests” e o certificado estará listado, bastando clicar com o botão direito e escolher Issue (Aprovar) ou Reject (Rejeitar).

Feito a aprovação o certificado está disponível como na Figura 17, onde estão listados os certificados emitidos. Para revogar um certificado você poderá clicar em qualquer um destes e escolher Revoke (Revogar), que ele irá passar a constar na lista CRL vista anteriormente.

Figura 17 - Liberando os certificados na ferramenta de administração da certificadora

Agora volte na página onde o certificado foi solicitado e escolha a opção “View status of pending request”. Seu certificado já está aguardando para ser copiado, como mostra a Figura 13. Basta clicar e salvá-lo em um local apropriado.

Figura 18 - Recebendo o certificado após a liberação

Nota
O certificado que você acabou de baixar (arquivo cer) não contem a chave privada, apenas a chave pública. A chave privada são os dados que geraram o arquivo texto PKCS no IIS e precisa agora ser complementado pela chave pública gerada e guardada no arquivo cer.

ATENÇÃO: Não adianta ter uma cópia do arquivo cer e tentar utilizá-lo novamente. Veremos a frente como fazer backup do certificado completo (chaves públicas+privada).

Com o arquivo do certificado em mãos, vamos terminar o processo no IIS. Volte no seu web site e utilizando o painel de ações do lado direito, Figura 19, escolha a opção “Complete Certificate Request”. Lembre-se conforme a note acima que é neste momento que se fará a ligação entre a chave privada do IIS com a chave pública enviada pelo CA.

Figura 19 – Completar o processo de instalação do certificado emitido para o servidor IIS

O próximo passo consiste em configurar o site para utilizar certificados. Para isso siga ao site como na Figura 20 e clique em “SSL Settings”.

Figura 20 - Tela de configuração do Site

Na Figura 21 podemos adicionar a porta que será utilizada para o SSL, a porta padrão é 443, e na Figura 22 podemos escolher o certificado que irá ser usado na criptografia dos dados.

Figura 21 - Opções de binding do certificado ao site

Figura 22 - Associando o certificado instalado à porta correspondente do Site

Nota
Uma interessante alteração no IIS 7 é que agora podemos ter para um mesmo site vários certificados diferentes, um para cada porta SSL, o que permite por exemplo, o site certificar na porta X o usuário utilizando o certificado do ICP-Brasil e na porta Y um certificado com nossa própria CA.
Isso não era possível no IIS até a versão 6, cada site utiliza um único certificado de CA.

Parte 3: Emitindo e certificando o usuário

Terminada a certificação do servidor precisamos certificar os usuários. Como a configuração do servidor exige certificados para acesso ao site o processo de certificação do usuário se tornou imprescindível e não apenas recomendado como anteriormente.

Para emissão instrua o usuário a acessar a certificadora pelo mesmo link utilizado para emitir o certificado do IIS, descrito na Figura 13. Processa com a opção de solicitação e no tipo de certificado escolha novamente “Advanced certificate request” e na tela seguinte a opção para submit de formulário, onde o usuário irá preencher os dados e receberá a informação para aguardar a liberação.

Vá à ferramenta “Active Directory Certificate Authority” como descrito anteriormente e libere o certificado. Instrua o usuário a retornar ao site da certificadora e escolher a segunda opção para receber o certificado como mostra a Figura 18. Ao clicar em “Install Certificate” o certificado é automaticamente instalado na máquina do usuário, diferente do processo quando para o servidor que o certificado é apenas copiado.

Após este processo o usuário já possui os certificados instalado na máquinas, como pode ser visto na tela do próprio IE (Tools -> Content -> Certificates) como na Figura 23 e 24.

Figura 23 - Opções do IE

Figura 24 - Certificado do usuário instalado

Concluído este processo o usuário já irá conseguir acessar o seu site de forma autenticada e será possível suas páginas com o código apresentado anteriormente identificar o usuário e ler os dados que foram preenchidos no formulário da certificadora, que pode ser acessada localmente ou mesmo pela internet se o seu servidor estiver publicado.

Dicas

Dica 1: Lembre-se de fazer backup do “System State” periodicamente. No Windows 2008 tambem é possível fazer backup clicando na ferramenta “Active Directory Certificate Autority”com o botão direito e escolher Backup. Isso é importante porque perder a certificadora causa a perda também da CRL (Certificate Revogation List) que irá impedir que mesmo os certificados JÁ EMITIDOS sejam utilizados.

Dica 2: Este ponto e o abaixo tem a ver com o mesmo problema. Se a sua certificadora for interna irá aparecer na tela o aviso de que o computador do usuário não confia no seu certificador, por este não ser um daqueles autorizados internacionalmente comentados no inicio.

Neste caso você pode importar o “Chain” que é o certificado da autoridade certificadora. Para isso acesse a página web da CA e escolha a opção “Download a CA certificate” conforme a Figura 25.

Figura 25 - Download do certificado do CA

Agora envei este certificado ao cliente, lembrando que não há perigo já que no arquivo CER não existe a chave privada. Clique no arquivo CER do certificado e escolha a opção “Import”. Ao fazer isso abrirá o wizard de importação e você irá colocar o certificado no repositório de certificadoras confiáveis, como a Figura 26 abaixo demonstra.

Figura 26 - Registrando a CA no computador cliente

Dica 3: Se o seu site está na internet e você precisa acabar com o erro comum “Certificate revogation List not accessible” altere o caminho do arquivos CRL que os certificados utilizam.

Isso é simples de ser feito, mas é importantíssimo. Clique na ferramenta de configuração do certificador e peça propriedades. Note na Figura 27 que é possível alterar o local onde a CRL será distribuída.

Alterando este valor procure os arquivos de extensão CRM no diretório “Windows\System32\CertSrv\CertEnroll” do servidor e copie estes para o seu servidor web.

Figura 27 - Alterando o caminho do CRL

Dica 4: Quando o usuário não terá acesso ao formulário pelo site e quem irá emitir será o administrador, como fazer para instalar no usuário?

Neste caso você poderá fazer todo o processo de uma maquina na sua rede interna. A sequencia é a mesma da citada na parte 3. Ao ter o certificado emitido na maquina interna, basta você exportar o certificado utilizando o padrão PKCS. Veja na Figura 23 e 24 e entre nas opções do IE, escolha o certificado e utilize o botão “Export”.

Ao clicar no Export  será executa o “Certificate Export Wizard”, onde você deverá exportar a chave privada junto com o certificado, como mostra a Figura 28 abaixo.

Figura 28 - Exportando certificados

Note na Figura 29 que as opções “Include all...” e “Export extend...” devem estar checados para que funcione o certificado, mas cuidado para não escolher a opção que deleta a chave privada, senão o certificado da máquina interna estará inválido após o processo de exportação.

Figura 29 - Opções de exportação do certificado

Para finalizar defina uma senha para o arquivo PFX que será gerado. Esta senha será importante para o usuário instalar em sua máquina o certificado.

Por fim, observe na Figura 30 o processo do usuário destino. Basta que ele dê duplo clique sobre o certificado e na tela do wizard de importação utilizar o ultimo dos três checkbox habilitados.

Figura 30 - Importando o certificado no cliente

Nota

Caso no wizard de importação você escolha a opção “Enable strong protection” o usuário irá ter que digitar uma senha, um PIN, todas as vezes em que o certificado for utilizado.

A opção “Mark key as exportable” não é aconselhável, já que isso permitiria que o usuário externo exporte o certificado e instale em outras máquinas.

Dica 5: Caso queira me certificar que realmente tenha sido o usuário que acessou e assinou digitalmente um documento, o que devo guardar?

Neste caso você pode acessar as propriedades do certificado e ler o Thumbprint que é um identificador único de um certificado, como mostra a Figura 31 abaixo.

Figura 31 - Propriedades do certificado (Thumbprint)

Conclusões

Neste artigo abordamos o que são os certificados digitais, como funcionam, a estrutura que existe para funcionamento e sua utilização no servidor web. Vale a pena lembrar novamente que o e-CPF/e-CNPJ são certificados e que o ICP-Brasil nada mais é do que uma certificadora, portanto todos os exemplos aqui são válidos. Inclusive o modo como administramos a solicitação, a liberação e a instalação dos certificados é a mesma utilizada pelas certificadoras comercias, apenas com interfaces mais elaboradas.

A utilização dos certificados digitais é simples mas poderosa permitindo autenticação segura do usuário.

Vemos que a segurança ganha com o processo é muito maior que o custo envolvido, principalmente quando lembramos que uma fraude utilizando o nome de outra pessoa é responsabilidade do site e não do cliente que foi fraudado segundo o Código do Consumidor.

Referências + Tópicos Relacionados

http://www.icpbrasil.gov.br/

Site oficial do ICP Brasil (Infra-estrutura Chaves Públicas).

http://www.certisign.com.br/home

Uma das mais importantes certificadoras mundiais, que vende o e-CPF e o e-CNPJ.

Sobre o autor

Marcelo Sincic (ms@avancoinformatica.com.br) é certificado Microsoft como MCT, MCITP, MCPD, MCTS, MCSA, MCDBA, MCAD, pela IBM como CLP Domino 6.5 e pela SUN como Java Trainer. Atualmente como consultor e instrutor ministrando treinamentos em .NET e plataforma Microsoft, mas é desenvolvedor desde 1989 com Clipper S’87 e Dbase III rodando Novell 2.1. Bons tempos aqueles...
Recebeu o prêmio Latin American MCT Awards no MCT Summit 2009 e o prêmio IT HERO da equipe Microsoft Technet Brasil em reconhecimento a projeto desenvolvido.