Usando um certificado reconhecido

Finalmente, temos a configuração para um certificado reconhecido, que será assinado por uma entidade certificadora, que você utilizaria em um site de comércio eletrônico aberto ao público.

Uma das entidades certificadoras mais tradicionais é a Verisign (http://www.verisign.com/), que oferece uma série de garantias sobre os certificados emitidos. O grande problema com relação à Verisign é o preço: o certificado de validação mais simples custa nada menos de US$ 499 anuais, com opções de até US$ 1499. Com preços tão altos, não é de se estranhar que existam inúmeras outras entidades certificadoras, que oferecem preços mais competitivos.

Alguns exemplos são a Thawte (http://www.thawte.com) a GeoTrust (http://www.geotrust.com), a NetworkSolutions (http://www.networksolutions.com), a Digicert (http://www.digicert.com/) e a Comodo (http://www.instantssl.com), que possui opções a partir de US$ 79 anuais.

A Comodo é a mesma empresa que desenvolve o Comodo Firewall, distribuído gratuitamente como uma forma de divulgação dos serviços de certificação. No site está disponível também a opção de gerar um certificado de teste (válido por 90 dias) gratuitamente, que você pode usar para fins de teste, ou quando quiser colocar uma loja virtual no ar rapidamente, deixando para aderir a um dos planos pagos mais tarde:

Existem ainda casos de empresas que oferecem certificados de baixo custo, como a Godaddy (http://www.godaddy.com, a mesma que faz registro de domínios), que oferece certificados a partir de US$ 29.90.

Em termos de segurança, não existe muita diferença entre um certificado emitido pela Godaddy ou pela Verisign, as principais diferenças são o nível de validação e as garantias oferecidas por cada uma em caso de fraude ou de quebra da chave criptográfica. Assim como em outras áreas, o principal fator na decisão acaba sendo a questão da confiança.

Muitos serviços de hospedagem oferecem a possibilidade de utilizar um certificado compartilhado, onde a empresa responsável “empresta” seu próprio certificado para uso dos clientes, em troca de uma taxa de manutenção anual. Esta opção pode parecer interessante devido ao baixo custo e à facilidade de implementação, mas não é o mesmo que obter seu próprio certificado, já que muito provavelmente você precisará hospedar seu site em um subdomínio e os clientes verão o nome da empresa de hospedagem e não o nome da sua empresa ao examinarem as propriedades do certificado.

Existe ainda a possibilidade de obter um certificado gratuito no http://www.cacert.org/. Ele é reconhecido pela CAcert, mas o certificado raiz deles não vem pré-instalado na maioria dos navegadores, o que faz com que os clientes continuem recebendo a mensagem de certificado não válido ao acessar o servidor, de forma similar ao que temos ao usar um certificado self-signed.

Ao contratar os serviços de uma entidade certificadora, sua parte no trabalho é a de gerar uma chave de encriptação e uma requisição de certificado, o que é novamente feito usando o openssl:

# openssl req -new -nodes -keyout gdhn.key -out gdhn.csr

O “gdhn.key” e o “gdhn.csr” indicam os arquivos com a chave e com a requisição do certificado que serão gerados. Você precisará responder as mesmas perguntas sobre o país, estado, cidade, nome da empresa, etc., que precisam ser respondidas corretamente, já que as informações serão examinadas não apenas pela entidade certificadora, mas também pelos clientes:

Country Name (2 letter code) [AU]: BR
State or Province Name (full name) [Some-State]: Estado
Locality Name (eg, city) []: Cidade
Organization Name (eg, company) []: Minha Empresa LTDA
Organizational Unit Name (eg, section) []: Vendas
Common Name (eg, YOUR name) []: ssl.minhaempresa.com.br

Como comentei anteriormente, o campo “Common Name” deve ser preenchido com o domínio onde o certificado será usado (incluindo o “www” ou o subdomínio usado), caso contrário os clientes receberão um aviso ao acessarem o site:

Em geral, as entidades certificadoras oferecem a opção de obter um certificado curinga (wildcard), que cobre automaticamente todos os subdomínios usados no site. Entretanto, como eles abrem a possibilidade de usar vários subdomínios usando um único certificado, as certificadoras cobram bem mais caro por eles. A Comodo, por exemplo, cobra nada menos do que US$ 449.95 anuais, mais de 5 vezes o valor do certificado regular:

No final do processo, o openssl oferece a opção de especificar uma senha (challenge password) para o certificado. É importante deixá-la em branco, caso contrário você precisará fornecê-la cada vez que o servidor web for iniciado, incluindo casos de reboots acidentais. O arquivo do certificado é armazenado em uma pasta protegida do servidor, fora do diretório disponível para a web, de forma que se um atacante chega ao ponto de obter acesso a ele, significa que o problema é mais embaixo e ele muito provavelmente já obteve acesso completo ao servidor de qualquer forma.

Depois de gerar a requisição, o próximo passo é enviar o arquivo .csr para a entidade certificadora, que o usará para gerar o certificado. O arquivo .csr é na verdade um arquivo de texto plano, cujo conteúdo pode ser copiado e colado em um formulário web. Depois de confirmada sua identidade e feito o pagamento, você receberá de volta o certificado assinado, que pode ser então usado na configuração do Apache.

A configuração consiste em adicionar as linhas “SSLCertificateFile” e “SSLCertificateKeyFile”, indicando a localização dos arquivos .crt e .key recebidos. Em muitos casos, você receberá também um terceiro arquivo, com extensão “ca-bundle” ou similar, que é usado em conjunto com uma terceira opção, a “SSLCertificateChainFile”.

Este terceiro arquivo contém uma combinação de certificados, que permitem aos clientes chegarem até o certificado raiz da entidade certificadora, de forma a comprovarem a autenticidade do seu certificado. Devido a isso, ele é também chamado de certificado intermediário (Intermediate Certificate). Temos aqui um exemplo de configuração com as três opções:

<VirtualHost *:443>
DocumentRoot /var/www/gdhn
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

O processo de emissão do certificado inclui uma verificação de identidade, que é justamente um dos principais papéis da entidade certificadora, já que se qualquer um pudesse gerar certificados válidos no nome de qualquer outro, o sistema perderia completamente o sentido. Nos planos mais simples, como no certificado gratuito oferecido pela Comodo, é feita uma simples verificação de titularidade via e-mail, onde você deve confirmar um código enviado para uma conta administrativa, como “admin@meudominio” ou “hostmaster@meudominio”. Nos planos mais caros (onde a entidade certificadora realmente oferece garantias, inclusive financeiras sobre o certificado emitido), o processo é mais burocrático, incluindo o envio de documentos.