How encryption with certificates and public/private keys work

README.md

PKI is based upon two keys (public and private)
Data can be securely encrypted using either the public or private keys
Data can only be decrypted when using the opposite key to that which encrypted the data
Use a Key Generator (e.g. ssh-keygen) to create your public/private keys
These keys are typically stored in ~/.ssh/
- id_rsa (private key; do not share! typically used to decrypt data)
- id_rsa.pub (public key; typically used to encrypt data)
Note: any data encrypted with a private key can be decrypted using the public key (and vice versa)
- A public key can be generated from a private key (not the other way around)

Data sent back and forth inside the browser can be encrypted using the Secure-Socket Layer (SSL) protocol
SSL uses public-key cryptography (PKI)

The public key should be added to .ssh/authorized_keys on all computers where the user wishes to log in
- The remote computer encrypts data with your public key
- Your private key decrypts the data when logging in (thus proving your identity)

RAs are companies in the business of allowing the public to trust an organisation’s encryption keys
If a website want’s their encrypted website to be trusted, then they’ll go to the RA (see “Banking” example below)

CA is nothing more than another public/private key pair (created by an RA)
The RA’s private key is (as you can imagine) private
The RA’s public key is available to everyone
- All computers sold, have a copy of these public root certificates
The RA’s private key is used to sign (encrypt) an organisation’s public key
A users web browser should be able to use the RA’s public key (CA cert) to decrypt an organisations public key when visiting that website
- Thus proving the organisation’s key can be trusted (and hasn’t been tampered with -> see “Banking” example below)

There is a hierarchy of CA certificates, the highest ranking CA’s certificate can’t be verified by anyone (as they’re the top of the chain) and so it must be “self-signed” (these are also referred to as “root certificates”)
You may wish to test your new SSL implementation while the CA is signing your certificate, and so “self-signing” is a temporary measure for testing your web service
[Update by @sthulb] Self signed certs are common in enterprises, for example it could be perceived that a company can trust a self signed cert more than a publicly signed cert since they can guarantee the entire CA chain

Alice uses Bob’s public key to send him a message
Bob’s public key is public, so how does he know Alice really sent the message?
RSA can be used to “sign a message”
Alice can prove who she is by sending Bob a signed message
Alice encrypts the message (using her private key), thus producing a hash
This hash is attached to the email as a “signature”
Bob uses the same hashing algorithm (using Alice’s public key) to encrypt the original (unencrypted) message, thus producing a hash
If the hash Bob creates matches the hash sent along with the message then we know Alice really sent the email (i.e. the sender was in possesion of Alice’s private key)

A bank wishes to encrypt their website that you use to manage your account
The bank wants to use a 3rd party to verify the authenticity of their private/public keypair
- Without this the user will see a “untrusted” warning in their web browser
The bank sends their public key to an RA
The bank pays the RA to sign (i.e. encrypt) their public key, using the RAs private key
Your web browser visits the banks website and is given the banks encrypted public key
Your web browser looks up the CA (which is installed on your computer) and decrypts the banks public key
Your web browser can now use the bank’s (now decrypted) public key to encrypt any data you send to it
The bank is the only person who has their private key and so are the only people able to decrypt your web browser’s message
- And vice versa, the bank can now send messages encrypted using their private key, as your web browser has the (decrypted) public key allowing you to decrypt any further encrypted messages from the bank

Note: the list below has been partially copied/modified from an answer here: http://serverfault.com/a/9717 as well as other sources

.pem is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. The name is from Privacy Enhanced Email, a failed method for secure email but the container format it used lives on, and is a base64 translation of the x509 ASN.1 keys (i.e. X.509 certificate).
.key is a PEM formatted file containing just the private-key of a specific certificate and is merely a conventional name and not a standardized one. In Apache installs, this frequently resides in /etc/ssl/private. The rights on these files are very important, and some programs will refuse to load these certificates if they are set wrong.
.p12 (also .pkcs12 and .pfx) is a password protected container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. OpenSSL can turn this into a .pem file with both public and private keys: openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem -nodes
.cert (also .cer and .crt) is a .pem formatted file with a different extension, one that is recognized by Windows Explorer as a certificate, which .pem is not.
cacert.pem is a collection of trusted root certification authorities