Questão Qual é a diferença entre um certificado e uma chave em relação ao SSL?


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?


81


origem


Certs usados ​​para SSL são fortemente baseados em PKI en.wikipedia.org/wiki/Public-key_cryptography - Zoredache


Respostas:


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.


71



Um certificado tem o componente público de uma chave, não a chave inteira. - Zoredache
Eu fiz correções. :) - LawrenceC
@Zoredache Se um certificado geralmente tem apenas uma chave pública, existe um bom nome para chamar arquivos .p12 ou .pfx que contenham certificados e chaves privadas juntos? - drs
Onde esta informação adicional é enterrada? Eu estava olhando para alguns certificados e é tudo rabugento para mim - CodyBugstein
A tagarelice que você está vendo é a codificação Base64. É feito dessa maneira provavelmente por uma razão similar que os anexos de email são convertidos para isso - basicamente para garantir que eles possam transportar através de protocolos e mecanismos projetados para ASCII apenas sem modificação casual e sem se preocupar com coisas como novas linhas, colchetes, etc. opensslcomando pode decodificar e analisar estes ou você pode usar um utilitário on-line como este: lapo.it/asn1js - LawrenceC


Vamos dizer que a empresa A tem um par de chaves e precisa publicar sua chave pública para uso público (também conhecido como ssl em seu site).

  • A empresa A deve fazer uma solicitação de certificado (CR) a uma autoridade de certificação (CA) para obter um certificado para seu par de chaves.
  • A chave pública, mas não a chave privada, do par de chaves da empresa A é incluída como parte da solicitação de certificado.
  • A autoridade de certificação, em seguida, usa informações de identidade da empresa A para determinar se a solicitação atende aos critérios da autoridade de certificação para emitir um certificado.
     Se a CA aprovar a solicitação, ela emite um certificado para a empresa A. Em resumo, a CA assina a chave pública da empresa A com a chave privada (da CA), que verifica sua autenticidade.

Portanto, a chave pública da empresa A assinada com uma chave privada da CA válida é denominada certificado da empresa A.


30



A Empresa A, em algum momento, associa sua chave privada (Empresa A) ao seu certificado (Empresa A)? - Tola Odejayi
Não. Uma chave privada permanece privet para A. - Mohsen Heydari
Então, onde é usada a chave privada da empresa A? - sivann
Após as formalidades acima. A empresa A terá um certificado SSL válido em seu site. Qualquer visitante (navegador) comunicando o site usará a chave pública do certificado para criptografar sua mensagem. A empresa A com a chave privada do certificado SSL é a única que pode descriptografar a mensagem. - Mohsen Heydari


Essas duas fotos juntas me explicaram tudo:

Fonte: linuxvoice

enter image description here

Fonte: infosecinstitute

enter image description here


29



Xkcd relevante - Blacksilver


Um SSL certificado é 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 de chaves SSL

Vários SSL chaves pode ser gerado 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. Por outro lado, as chaves SSL ou as chaves de sessão são geradas exclusivamente durante a sessão e descartadas quando a sessão é encerrada.

Leia mais aqui


3





OK, vamos dividir isso para que 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 leva 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 que você possa realmente abrir o 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 (contanto que você possa ser identificado (confiável) e tenha a chave certa).


1



<PiratesOfTheCarribean> Então vamos atrás dessa chave! </ PiratesOfTheCarribean> (Leia: Você não está fazendo nenhum sentido ...) - Timo


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.

Demonstração (Você pode gerar um certificado e uma chave privada): http://www.selfsignedcertificate.com/

Você pode baixar o arquivo de chave privada e arquivo de certificado, você vê arquivo de certificado contém muita informação como mostrado abaixo. enter image description here enter image description here

Você pode combinar seu certificado gerado (abertura por um editor de texto) e chave privada (abertura por um editor de texto) deste site: https://www.sslshopper.com/certificate-key-matcher.html

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 em apenas 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 este problema é ter o cliente um conjunto de um ou mais certificados em que confia. 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 fortes 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 curinga, 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 facilmente saber se está se comunicando com o servidor ou não.


1





Navegador e servidor de comunicação

Aperto de mão:

  • Cliente envia um número aleatório junto com a criptografia suportada
  • Servidor envia seu certificado com criptografia suportada. E o número aleatório do cliente é criptografado com sua chave privada e é enviado de volta. O certificado contém a chave pública. Emissor do Certificado ou (CA), Expiração, etc.
  • Cliente Verifica o certificado enviado pelo servidor.

Todo 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 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 banco de dados da CRL.

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


-2



Eu entendo que não responde diretamente a pergunta, mas por favor, comente quando downvoting. - Kid101