I have a need to have somebody else encrypt secret data with my public key that I can then decrypt with my private key. I have produced an RSA private/public key pair with OpenSSL gave them the public key and have everything working.

More recently, somebody pointed out that we are subject to a possible man-in-the-middle attack where the bad guys would accept my public key and pass their own public key to the other side. The other side would then dutifully encrypt the secret data, pass it to the MITM who would decrypt it, reencrypt it with my public key before passing it on to me without my being the wiser. The recommended solution is to have my public key signed by a CA that the other side trusts before passing it over.

As an experiment, I produced a CSR that I was able to sign with my own CA, but the resulting certificate contains the (encrypted) private key as well. I would rather not be passing my secret key to anybody else, encrypted or not.

Is there a way to just have my public key signed?

  • 1
    Certificate contains private key? Huh? How did you manage to do this? Can you post that file on pastebin.com? (Redo it with a second key pair so you don't have to share the original.) Dec 19, 2015 at 14:08
  • 2
    I think I am starting to understand. Even though I need the private key to produce a CSR, the CSR and the resulting certificate does not contain the private key. A certificate is effectively a signed public key which is exactly what I want. Dec 21, 2015 at 19:01

3 Answers 3


Signing a public key is effectively a certificate. These are the steps I take to produce a public key certificate I can distribute to other so that they may communicate securely with me:


  1. Generate the private Keys:

    openssl genrsa -out private.pem 2048

  2. Generate the public keys:

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

  3. Create a CSR (Certificate Signing Request)

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

  4. Create a Self-signed certificate (you can share this certificate)

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


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


  1. Extract the Public Key from the Certificates

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

  2. Decrypt the data

    openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data

If you intend on having your key signed by a CA you'll have to send your CSR file (and some cash) to your CA of choice, they'll give you have the certificate you can use instead of the self-signed cert I mentioned in the steps above.

  • This is kind of the reverse of what I am asking but it will do for the purposes of discussion. In order for the other side to decrypt, they either need the public key as extracted by me which is subject to the MITM attack or they need the whole certificate which includes the (encrypted) private key Dec 18, 2015 at 20:10
  • @user1683793 The other end needs two certificates. The first of which they should already have (the self-signed CA certificate). The second contains the public key that you want verified, and is signed with the CA certificate (using the associated CA private key). The validity of the second certificate is tested using the public key in the CA certificate. Private keys are always kept private. Dec 19, 2015 at 11:35
  • 1
    I think you want "-encrypt" and "-decrypt" instead of "-sign" and "-verify". (Details here: czeskis.com/random/openssl-encrypt-file.html) Dec 19, 2015 at 14:55
  • Not working: 2. Decrypt the data did not work for me. With: openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data I get this error/msg: A private key is needed for this operation
    – Cyborg
    Sep 4, 2017 at 23:56
  • 1
    SectionSetup, step 2 gives public.pem - it isn't used in any further steps. What is the use of that public key when the CSR is being generated with private key?
    – Mubin
    Aug 16, 2019 at 7:56

There should be three entities involved in the process:

  1. The Sender - You
  2. The Receiver - The User
  3. Certificate Authority - Trusted Third Party (Or you in some cases)

The process that keeps things safe is "The Sender", generates a pair of keys (public and private). I like to refer to these as key and lock for a better visual. The key (private) should never leave The Sender's possession, that's why it's called a private key.

The Sender then generates a Certificate Signing Request (CSR) with the public key (lock) which is forwarded to the Certificate Authority (Trusted Third Party), the Certificate Authority signs the the public key (lock) with the Certificate Authorities private key.

The Certificate Authority now sends "The Senders" public key which is signed by the Certificate Authorities private key back to "The Sender", which is now the certificate.

The Receiver gets the certificate (lets say through the web browser) and verify's that it valid with the Certificate Authorities public key which both "The Sender" and "The Receiver" have since they are the trusted third party. Once verified the public key in the certificate can be trusted* to be "The Sender's" public key unaltered.

If "The Receiver" needs to send data to "The Sender", they would use the public key from the trusted certificate to encrypt the data into cypertext which then gets passed along to "The Sender". Since only "The Sender's" private key can decrypt the cyphertext that was encrypted with "The Sender's" public key anyone in the middle essentially has useless garbled text.

In certain cases "The Sender" can generate his/her own Certificate Authority by signing their own CSR with a different set of keys or self signing with the same set of keys. In this case "The Sender's" public key needs to be known by both parties through a secure channel to have any trust. In software you can include a certificate into the deliverable that can be used as the trusted third party.

*trusted is only valid if the Certificate Authority maintains a CRL (Certificate Revocation List) and all parties monitor the list to ensure that the issued certificate hasn't been compromised. The case where the certificate authority is comprimised and the private key is leaked exists and when that happens the compromising agent can use the private key to generate a trusted certificate that mimics "The Sender", in that case a MITM is possible and the MITM can receive data from "The Sender" decrypt, store, encrypt with a valid certificate that looks like "The Sender", then pass that to "The Receiver".


Take the encrypted private key out of the copy of the CA certificate that you created (when giving it to others). The private key does not need to be there unless you are going to use it to sign a certificate containing another public key.

When you are sending over your public key, instead send over an entire certificate (except for the private key), signed using the associated CA private key. In order to check the validity of the public key inside of it, you need to check the hash of the certificate against the encrypted hash (that was encrypted using the CA's private key). This is decrypted using the CA's public key. If the decryption is successful and the hash matches the hash of the certificate, then the information inside of the certificate can be trusted.

There is also more to it than just encryption, for example a replay attack in which an attacker sends previously saved encrypted data. TLS covers much more than the average person would think, and implementing a similar system is absolutely not recommended. Use TLS whenever possible for anything intended to be private.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .