Sempre que tento entender alguma coisa sobre SSL, sempre tenho dificuldade em acompanhar o que "chave" e "certificado" referem. Temo que muitas pessoas as usem de forma incorreta ou intercambiável. Existe uma 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ções adicionais, como o emissor, para que o certificado deve ser usado e outros tipos de metadados.
Normalmente, um certificado é assinado com uma chave privada que verifica sua autenticidade.
Digamos que a empresa A tenha um par de chaves e precise publicar sua chave pública para uso público (também conhecido como ssl em seu site).
Portanto, a chave pública da empresa A assinada com uma chave privada da CA válida é denominada certificado da empresa A.
Um certificado SSL é obtido de uma autoridade de certificação confiável, que garante a conexão segura do site. Os certificados SSL geralmente contêm o logotipo de autenticação e também as chaves públicas necessárias para criptografar e descriptografar os dados que devem ser enviados ao computador. Funções das Chaves SSL
Várias chaves SSL podem ser geradas durante uma sessão. Eles são usados para criptografar e descriptografar as informações enviadas para e do computador. As chaves são usadas para verificar se as informações não foram modificadas ou adulteradas.
Diferença do ciclo de vida
Os certificados duram mais que as chaves SSL. Os certificados SSL são obtidos da Autoridade de Certificação, que pode ser renovada regularmente por bancos e empresas. 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
Deixe-me explicar com um exemplo.
Na PKI baseada em pares de chaves normais, há chave privada e chave pública.
Em um sistema baseado em certificado, há chave privada e certificado. O certificado contém mais informações do que a chave pública.
Demo (Você pode gerar um certificado e uma chave privada): link
Você pode fazer o download do arquivo de chave privada e do arquivo de certificado. Você verá que o arquivo de certificado contém muitas informações, conforme mostrado abaixo.
Vocêpodecombinarseucertificadogerado(aberturaporumeditordetexto)echaveprivada(aberturaporumeditordetexto)destesite:
Se o certificado corresponder à chave privada do cliente, o cliente tem certeza de que o certificado é fornecido pelo cliente ou fornecido pelo agente confiável do cliente (CA).
No entanto, existem problemas apenas na comunicação por chave privada e por certificado .
Como qualquer pessoa pode gerar seu próprio certificado e chave privada, um simples handshake não prova nada sobre o servidor, exceto que o servidor conhece a chave privada que corresponde à chave pública do certificado. Uma maneira de resolver esse problema é fazer com que o cliente tenha um conjunto de um ou mais certificados confiáveis. Se o certificado não estiver no conjunto, o servidor não é confiável .
Existem várias desvantagens nessa abordagem simples. Os servidores devem poder atualizar para chaves mais strongs ao longo do tempo ("rotação de chaves"), que substitui a chave pública no certificado por uma nova. Infelizmente, agora o aplicativo cliente precisa ser atualizado devido ao que é essencialmente uma alteração na configuração do servidor. Isso é especialmente problemático se o servidor não estiver sob o controle do desenvolvedor do aplicativo, por exemplo, se for um serviço da Web de terceiros. Essa abordagem também tem problemas se o aplicativo tiver que conversar com servidores arbitrários, como um navegador da Web ou um aplicativo de e-mail.
Para resolver essas desvantagens, os servidores geralmente são configurados com certificados de emissores conhecidos, chamados Autoridades de Certificação (CAs). A plataforma host (cliente) geralmente contém uma lista de CAs bem conhecidas nas quais ele confia. Semelhante a um servidor, uma CA tem um certificado e uma chave privada. Ao emitir um certificado para um servidor, a CA assina o certificado do servidor usando sua chave privada. O cliente pode então verificar se o servidor possui um certificado emitido por uma autoridade de certificação conhecida na plataforma.
No entanto, ao resolver alguns problemas, o uso de CAs introduz outro. Como a CA emite certificados para muitos servidores, você ainda precisa de alguma maneira para se certificar de que está falando com o servidor que deseja. Para resolver isso, o certificado emitido pela CA identifica o servidor com um nome específico, como gmail.com ou um conjunto de hosts com curingas, como * .google.com.
O exemplo a seguir fará com que esses conceitos sejam um pouco mais concretos. No trecho abaixo de uma linha de comando, o comando s_client da ferramenta openssl examina as informações sobre o certificado do servidor da Wikipedia. Especifica a porta 443 porque esse é o padrão para HTTPS. O comando envia a saída do openssl s_client para o openssl x509, que formata informações sobre os certificados de acordo com o padrão X.509. Especificamente, o comando solicita o assunto, que contém as informações sobre o nome do servidor, e o emissor, que identifica a autoridade de certificação.
$ 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
Você pode ver que o certificado foi emitido para servidores que correspondem a * .wikipedia.org pela CA RapidSSL.
Como você pode ver, devido a essas informações adicionais enviadas pela CA aos Servidores, o cliente pode saber com facilidade se está se comunicando com o servidor ou não.
OK, vamos dividir isso para que as pessoas não técnicas possam entender.
Pense nisso assim. Um certificado é como um cofre no seu banco. Ele contém muitas coisas importantes; geralmente coisas que contém sua identidade. O certificado tem uma chave pública e precisa de uma chave privada para abri-lo.
Seu cofre tem duas chaves para abrir também, assim como um certificado.
Com um cofre, a chave do banqueiro é como a chave pública, uma vez que fica no banco e a chave pública fica com o certificado. Você tem a chave privada, que é necessária para "obter seu certificado" e, no exemplo do cofre, sua chave privada também é necessária, além da chave pública.
Antes de poder abrir seu cofre, você deve primeiro verificar sua identidade (como uma solicitação de certificado); Depois de ter sido identificado, você usa sua chave privada junto com a chave pública para abrir o seu cofre. Isso é um pouco como fazer sua solicitação de certificado e depois obter seu certificado da autoridade de certificação (desde que você possa ser identificado (confiável) e tenha a chave certa).
Comunicação entre navegadores e servidores
HandShake:
Todo o PC vem com uma lista de CA em quem eles confiam, como VeriSign ou DigiCert. Estas são CA raiz.Todas as CA raiz são auto-assinadas. Para entender. É como se eu confiasse no Servidor A e o Servidor A conhecesse o Servidor B, então o Servidor A pode atestar que este é o Servidor B que ele diz ser. E maneira Servidor O voto é fornecendo o Certificado para o Servidor B. Este certificado é na verdade Singed by Private Key da CA no nosso caso Servidor A. quem é a assinatura pública já está em nosso PC com o qual eu posso verificar a autenticidade do certificado fornecido pela Servidor B.
O cliente Verifica a mensagem ou o número aleatório que enviou antes, com a chave pública (recebida no certificado).
Agora o cliente verifica se o certificado é válido enviando uma solicitação OCSP e verificando o CRL DB.
Agora, se o Certificado não tiver sido revogado, um par de chaves de sessão será estabelecido com o qual um túnel de criptografia é estabelecido, agora todo o tráfego é criptografado.
Todas as Solicitações de CSR são assinadas por Certificados Intermediários, e não pela CA Raiz diretamente, para reservar a integridade da CA ROOT, para que não sejam comprometidas.