How do I produce a CA signed public key?

Question

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?

Answer 1

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:

Setup

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

Encrypting

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

Decrypting

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.

Answer 2

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

Answer 3

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.