Sempre que tento compreender alguma coisa sobre SSL tenho sempre dificuldade em acompanhar o que se refere a “chave” e “certificado”. Receio que muitas pessoas as utilizem de forma incorrecta ou intercambiável. Existe alguma diferença padrão entre uma chave e um certificado?
Um certificado contém uma chave pública.
O certificado, além de conter a chave pública, contém informação adicional, tal como o emissor, para que é que o certificado deve ser utilizado, e outros tipos de metadados.
Tipicamente, um certificado é assinado por uma autoridade certificadora (AC) utilizando a chave privada da AC. Isto verifica a autenticidade do certificado.
Estas duas imagens juntas explicaram-me tudo:
Fonte: linuxvoice
Fonte: infosecinstitute
Digamos que a empresa A tem um par de chaves e precisa de publicar a sua chave pública para uso público (aka ssl no seu sítio web).
Assim, a chave pública da empresa A assinada com uma chave privada válida do AC chama-se certificado da empresa A.
Deixem-me explicar com um exemplo.
Em PKI normal baseado em pares de chaves, existem chaves privadas e chaves públicas.
Num sistema baseado em certificado, há chave privada e certificado. O certificado detém mais informação do que a chave pública.
Demo (É possível gerar um certificado e uma chave privada): http://www.selfsignedcertificate.com/
Pode descarregar o ficheiro de chave privada e o ficheiro de certificado, verá que o ficheiro de certificado contém muita informação como se mostra abaixo.
Pode combinar o certificado gerado (abertura por um editor de texto), e a chave privada (abertura por um editor de texto) a partir deste sítio: https://www.sslshopper.com/certificate-key-matcher.html
Se o certificado corresponder à chave privada do cliente, o cliente tem a certeza, esse certificado é dado pelo cliente ou dado pelo agente de confiança do cliente (CA).
No entanto, existem problemas apenas na comunicação baseada em chave privada e certificado*.
Porque, qualquer pessoa pode gerar o seu próprio certificado e chave privada, por isso um simples aperto de mão não prova nada sobre o servidor a não ser que o servidor conhece a chave privada que corresponde à chave pública do certificado. Uma forma de resolver este problema é o cliente ter um conjunto* de um ou mais certificados em que confia. Se o certificado não estiver no conjunto, o servidor não é de confiança*.
Há várias desvantagens nesta abordagem simples. Os servidores devem ser capazes de actualizar para chaves mais fortes ao longo do tempo (“rotação de chaves”), o que substitui a chave pública no certificado por uma nova. Infelizmente, agora a aplicação cliente tem de ser actualizada devido ao que é essencialmente uma mudança na configuração do servidor. Isto é especialmente problemático se o servidor não estiver sob o controlo do desenvolvedor da aplicação, por exemplo, se for um serviço web de terceiros. Esta abordagem também tem problemas se a aplicação tiver de falar com servidores arbitrários, tais como um navegador web ou uma aplicação de correio electrónico.
A fim de resolver estas desvantagens, os servidores são tipicamente configurados com certificados de emissores bem conhecidos chamados Autoridades Certificadoras (AC). a plataforma anfitriã (cliente) contém geralmente uma lista de ACs bem conhecidas em que confia. Semelhante a um servidor, uma AC tem um certificado e uma chave privada. Ao emitir um certificado para um servidor, a AC assina o certificado do servidor utilizando a sua chave privada. O cliente pode então verificar que o servidor tem um certificado emitido por uma AC conhecida da plataforma.
Contudo, ao resolver alguns problemas, a utilização de AC introduz outra. Como a AC emite certificados para muitos servidores, ainda é necessário alguma forma de se certificar de que está a falar com o servidor que pretende. Para resolver isto, o certificado emitido pela AC identifica o servidor ou com um nome específico como gmail.com ou um conjunto de hosts wildcarded como *.google.com.
O exemplo seguinte tornará estes conceitos um pouco mais concretos. No snippet abaixo, a partir de uma linha de comando, o comando openssl s_client da ferramenta s_client examina a informação do certificado do servidor da Wikipedia. Especifica a porta 443 porque essa é a predefinição para HTTPS. O comando envia a saída do openssl s_client para openssl x509, que formata informação sobre certificados de acordo com a norma X.509. Especificamente, o comando pede o assunto, que contém a informação do nome do servidor, e o emissor, que identifica a AC.
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
Pode ver que o certificado foi emitido para servidores correspondentes a *.wikipedia.org pela RapidSSL CA.
Como pode ver, devido a esta informação adicional enviada pela CA aos Servidores, o cliente pode facilmente saber se está ou não a comunicar com o seu servidor.
Um certificado SSL certificado* é obtido de uma Autoridade de Certificação de confiança, que garante a ligação segura do website . Os certificados SSL contêm geralmente o logotipo de autenticação e também as chaves públicas necessárias para encriptar e desencriptar os dados que devem ser enviados para o computador. Funções das Chaves SSL
Várias chaves SSL keys* podem ser geradas durante uma sessão. As chaves são utilizadas para encriptar e desencriptar a informação a ser enviada para e do computador. As chaves são utilizadas para verificar que a informação não foi modificada ou adulterada.
Diferença de ciclo de vida
Os certificados duram mais do que as chaves SSL. Os certificados SSL são obtidos da Autoridade de Certificação, que pode ser renovada regularmente por bancos e empresas. As chaves SSL ou chaves de sessão, por outro lado, são geradas exclusivamente durante a sessão e descartadas quando a sessão termina. Leia mais aqui
OK, vamos decompor isto para que as pessoas não técnicas possam compreender.
Pense nisto desta forma. Um Certificado é como um cofre de segurança no seu banco. Contém um monte de coisas importantes; geralmente coisas que contêm a sua identidade. O certificado tem uma chave pública e precisa de uma chave privada para o abrir.
O seu cofre de segurança também precisa de duas chaves para abrir, tal como um certificado.
Com um cofre de segurança, a chave do banqueiro é como a chave pública uma vez que fica no banco e a chave pública fica com o certificado. Tem a chave privada, que é necessária para “obter o seu certificado” e, no exemplo do cofre de segurança, a sua chave privada é necessária para além da chave pública também.
Antes de poder realmente abrir o seu cofre de segurança, deve primeiro verificar a sua identidade (como um pedido de certificado); uma vez identificado, utiliza a sua chave privada juntamente com a chave pública para abrir o seu cofre de segurança. Isto é um pouco como fazer o seu pedido de certificado, e depois obter o seu certificado da autoridade de certificação (desde que possa ser identificado (confiável) e tenha a chave certa).