There should be three entities involved in the process:
- The Sender - You
- The Receiver - The User
- 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".