How encryption with certificates and public/private keys work

SSH Authentication

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)
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
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

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