Assinando uma chave pública é efetivamente um certificado. Estas são as etapas que realizo para produzir um certificado de chave pública que possa distribuir a outros para que eles possam se comunicar com segurança comigo:

Configuração

1. Gere as chaves privadas:
   

   openssl genrsa -out private.pem 2048

2. Gere as chaves públicas:
   

   openssl rsa -in private.pem -outform PEM -pubout -out public.pem

3. Criar um CSR (solicitação de assinatura de certificado)
   

   openssl req -new -key private.pem -out certificate.csr

4. Crie um certificado autoassinado (você pode compartilhar este certificado)
   

   openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt

Criptografia

openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data> encryption_data

Descriptografando

1. Extraia a chave pública dos certificados
   

   openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem

2. Descriptografe os dados
   

   openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encryption_data> dados

Se você pretende que sua chave seja assinada por uma CA, você terá que enviar seu arquivo CSR (e algum dinheiro) para a CA de sua escolha, eles lhe darão o certificado que você pode usar em vez do certificado auto-assinado I mencionado nas etapas acima.

Comentários

• Isso é mais ou menos o contrário do que estou pedindo, mas servirá para fins de discussão. Para que o outro lado decifre, eles precisam da chave pública extraída por mim que está sujeita ao ataque MITM ou precisam de todo o certificado que inclui a chave privada (criptografada)
• @ user1683793 O a outra extremidade precisa de dois certificados. O primeiro dos quais eles já deveriam ter (o certificado CA autoassinado). O segundo contém a chave pública que você deseja verificar e é assinado com o certificado CA (usando a chave privada CA associada). A validade do segundo certificado é testada usando a chave pública no certificado CA. As chaves privadas são sempre mantidas privadas.
• Acho que você deseja ” -encrypt ” e ” -decrypt ” em vez de ” -sign ” e ” -verify “. (Detalhes aqui: czeskis.com/random/openssl-encrypt-file.html )
• Não funciona: 2. Descriptografar os dados não funcionou para mim. Com: openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data recebo este erro / msg: A private key is needed for this operation
• Seção Setup, etapa 2 fornece public.pem – não é ‘ usado em mais nada degraus. Qual é a utilidade dessa chave pública quando o CSR está sendo gerado com a chave privada?

Deve haver três entidades envolvidas no processo:

1. O remetente – você
2. O destinatário – o usuário
3. Autoridade de certificação – Terceiro confiável (ou você em alguns casos)

O processo que mantém as coisas seguras é “The Sender”, gera um par de chaves (públicas e privadas). Gosto de me referir a eles como chave e cadeado para um melhor visual. A chave (privada) nunca deve sair da posse do remetente, por isso é chamada de chave privada.

O remetente então gera uma solicitação de assinatura de certificado (CSR) com a chave pública (bloqueio ) que é encaminhado para a autoridade de certificação (terceiro confiável), a autoridade de certificação assina a chave pública (bloqueio) com a chave privada da autoridade de certificação.

A autoridade de certificação agora envia a chave pública “Os remetentes” que é assinado pela chave privada das Autoridades de Certificação de volta para “O Remetente”, que agora é o certificado.

O Destinatário obtém o certificado (digamos através do navegador da web) e verifica se ele é válido com a chave pública das Autoridades de Certificação que “O Remetente” e “O Destinatário” possuem, uma vez que são a terceira parte confiável. Depois de verificada a chave pública no certificado, pode-se confiar * como a chave pública “do remetente” inalterada.

Se “O receptor” precisar enviar dados para “O remetente”, ele usará o chave pública do certificado confiável para criptografar os dados em cipertexto que é então repassado para “O Remetente”. Uma vez que apenas a chave privada de “O Remetente” pode descriptografar o texto cifrado que foi criptografado com a chave pública “O Remetente”, qualquer pessoa no meio, essencialmente, tem texto truncado inútil.

Em certos casos, “O remetente” pode gerar sua própria autoridade de certificação assinando seu próprio CSR com um conjunto diferente de chaves ou autoassinando com o mesmo conjunto de Neste caso, a chave pública “O Remetente” precisa ser conhecida por ambas as partes por meio de um canal seguro para ter alguma confiança. No software, você pode incluir um certificado na entrega que pode ser usado como o terceiro confiável.

* confiável só é válido se a Autoridade de Certificação mantiver uma CRL (Lista de Revogação de Certificados) e todas as partes monitorarem a lista para garantir que o certificado emitido não foi comprometido. O caso em que a autoridade de certificação é comprometida e a chave privada vaza existe e quando isso acontece, o agente comprometedor pode usar a chave privada para gerar um certificado confiável que imita “o remetente” , nesse caso um MITM é possível e o MITM pode receber dados de “O Remetente”, descriptografar, armazenar, criptografar com um certificado válido que se pareça com “O Remetente” e, em seguida, passá-lo para “O Destinatário”.

Retire a chave privada criptografada da cópia do certificado CA que você criou (ao fornecê-lo a outras pessoas). A chave privada sim não precisa estar lá, a menos que você vá usá-lo para assinar um certificado contendo outro er chave pública.

Quando você estiver enviando sua chave pública, em vez disso, envie um certificado inteiro (exceto a chave privada), assinado usando a chave privada CA associada. Para verificar a validade da chave pública dentro dele, você precisa verificar o hash do certificado em relação ao hash criptografado (que foi criptografado usando a chave privada da CA). Isso é descriptografado usando a chave pública da CA . Se a descriptografia for bem-sucedida e o hash corresponder ao hash do certificado, as informações dentro do certificado podem ser confiáveis.

Também há mais do que apenas criptografia, por exemplo, um ataque de repetição em que um invasor envia dados criptografados salvos anteriormente. O TLS cobre muito mais do que uma pessoa comum pensaria, e implementar um sistema semelhante não é absolutamente recomendado. Use o TLS sempre que possível para qualquer coisa que pretenda ser privada.