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


127

Sempre que tento entender alguma coisa sobre SSL, sempre tenho dificuldade em acompanhar o que "chave" e "certificado" se referem. Temo que muitas pessoas os usem de forma incorreta ou intercambiável. Existe uma diferença padrão entre uma chave e um certificado?


Certs utilizados para SSL é fortemente baseada em PKI en.wikipedia.org/wiki/Public-key_cryptography
Zoredache

Respostas:


115

Um certificado contém uma chave pública.

O certificado, além de conter a chave pública, contém informações adicionais, como emissor, para que o certificado deve ser usado e outros tipos de metadados.

Normalmente, um certificado é assinado por uma autoridade de certificação (CA) usando a chave privada da CA. Isso verifica a autenticidade do certificado.


4
@Zoredache Se um certificado normalmente apenas possui uma chave pública, existe um bom nome para chamar arquivos .p12 ou .pfx que contenham certificados e chaves privadas juntos?
drs

Um pkcs12 é um formato de arquivo. Pode conter uma chave, ou talvez não. Geralmente, tento sempre ser específico ao me referir ao que um arquivo específico contém, ou apenas dizer o arquivo pkcs12.
Zoredache

2
Onde essas informações adicionais estão enterradas? Eu estava olhando para alguns certificados e é tudo jargão para mim
CodyBugstein

3
A tagarelice que você está vendo é a codificação Base64. É feito dessa maneira provavelmente por uma razão semelhante em 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ções casuais e sem se preocupar com coisas como novas linhas, colchetes etc. O opensslcomando pode decodificar e analisar estes ou você pode usar um utilitário de linha como esta: lapo.it/asn1js
LawrenceC

O certificado assinado por uma CA ou servidor está sendo comunicado?
21717 Olshansk

58

Essas duas fotos juntas explicaram tudo para mim:

Fonte: linuxvoice

insira a descrição da imagem aqui

Fonte: infosecinstitute

insira a descrição da imagem aqui


1
Xkcd

Agradável. 1 esclarecimento: a 1ª foto é autenticação TLS padrão (unidirecional); o segundo, autenticação mútua (bidirecional). E uma chamada extra no primeiro ajudaria a explicar como a confiança é realmente estabelecida (tudo nessa foto de aparência mais amigável): depois que o cliente obtém o certificado de chave pública do servidor, o cliente verifica se a CA que assinou o O certificado do servidor está contido na lista particular do cliente de CAs confiáveis ​​(estabelecendo que agora ele também confia nessa CA). Em seguida, é seguro enviar ao servidor a chave da sessão, com a qual cada um agora pode criptografar e descriptografar as comunicações subsequentes.
user1172173

O primeiro link, para linuxvoice.com/… , fornece um erro de certificado. Irônico.
Tobb

37

Digamos que a empresa A tenha um par de chaves e precise publicar sua chave pública para uso público (também conhecida como ssl em seu site).

  • A empresa A deve fazer uma solicitação de certificado (CR) para 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 CA usa as informações de identidade da empresa A para determinar se a solicitação atende aos critérios da CA para emitir um certificado.
    Se a CA aprovar a solicitação, emite um certificado para a empresa A. Em resumo, a CA assina a chave pública da empresa A com sua chave privada (CA), que verifica sua autenticidade.

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


A Empresa A em algum momento associa sua chave privada (da Empresa A) ao seu certificado (da Empresa A)?
Tola Odejayi

Não. Uma chave privada permanece privada para A.
Mohsen Heydari

Então, onde é usada a chave privada da empresa A?
Sivann

2
Após as formalidades acima. A empresa A terá um certificado SSL válido em seu site. Qualquer visitante (navegador) que comunique o site usará a chave pública do certificado para criptografar sua mensagem. Empresa A que possui a chave privada do certificado SSL é a única pessoa que pode descriptografar a mensagem.
Mohsen Heydari

Eu acho que a empresa A é do sexo masculino.
DimiDak

5

Deixe-me explicar com um exemplo.

Na PKI normal baseada em par de chaves, 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 que a chave pública.

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

Você pode fazer o download, abrir o arquivo de chave privada e o arquivo de certificado. Você verá que o arquivo de certificado contém muitas informações, como mostrado abaixo. insira a descrição da imagem aqui insira a descrição da imagem aqui

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

Se o certificado corresponder à chave privada do cliente, ele terá certeza de que esse certificado é fornecido pelo cliente ou fornecido pelo CA (agente confiável) do cliente.

No entanto, existem problemas apenas na chave privada e na comunicação baseada em 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 nos quais 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 apresenta problemas se o aplicativo precisar conversar com servidores arbitrários, como um navegador da Web ou um aplicativo de email.

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 conhecidas em que confia. Semelhante a um servidor, uma CA possui 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 pela 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 de verificar se está conversando 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 caracteres curinga, como * .google.com.

O exemplo a seguir tornará esses conceitos um pouco mais concretos. No fragmento abaixo de uma linha de comando, o comando s_client da ferramenta openssl examina as informações de certificado do servidor da Wikipedia. Ele especifica a porta 443 porque esse é o padrão para HTTPS. O comando envia a saída de openssl s_client para openssl x509, que formata informações sobre certificados de acordo com o padrão X.509. Especificamente, o comando solicita o assunto, que contém as informações do nome do servidor, e o emissor, que identifica a CA.

$ 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 correspondentes 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 facilmente se está se comunicando com o servidor ou não.


3

Um certificado SSL é obtido de uma Autoridade de Certificação confiável, que atesta 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 a serem enviados ao computador. Funções de 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


2

OK, vamos detalhar 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 também tem duas chaves para abrir, como um certificado.
Com um cofre, a chave do banqueiro é como a chave pública, pois permanece no banco e a chave pública permanece com o certificado. Você possui a chave privada, 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 abrir seu cofre, você deve primeiro verificar sua identidade (como uma solicitação de certificado); depois de identificado, você usa sua chave privada e a chave pública para abrir sua caixa de segurança. É um pouco como fazer sua solicitação de certificado e obter seu certificado da autoridade de certificação (desde que você possa ser identificado (confiável) e tenha a chave certa).


3
<PiratesOfTheCarribean> Então, nós estamos indo atrás dessa chave! </PiratesOfTheCarribean> (Leia: Você não está fazendo nenhum sentido ...)
Timo
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.