1,234
edits
Changes
→Encryption, certificates, etc.
= Encryption, certificates, etc. =
You've been using public key cryptography for your entire life (unless you were born before the 1990s). And you've been setting up public key cryptography for yourself since at least OPS245. If you actually understand how this stuff works: you'll be far ahead of the average sysadmin. We don't have the time to do a comprehensive overview of cryptography, so I strongly encourage you to put the book '''Crypto''' by '''Steven Levy''' on your "must-read" list. You can borrow a copy from the Toronto Public Library. I have yet to see a better introduction to encryption. It's not a course reqirement - but if you don't want to be clueless about security fundamentals online - read that book and understand it. It is an engaging readreads like a novel, and it's perfectly readable even if you have no interest in math:
[[Image:crypto.jpeg|center|"crypto" by Steven Levy]]
== Certificate Authorities (CAs) ==
The problem with assymetric encryption is the distribution of public keys. The encryption strength is meaningless if the client can't be sure it has the unmodified public key for the server. That's where a third party gets involved. This third party is called a Certificate Authority.
The exact same concepts from the section above are used for CA-signed certificates. There's just a third party involved - which makes it seem like magic for too many people, including professionals in our field.
If you have any ambitions in this field: set a goal for yourself to understand this stuff fully. At least eventually, if not now.
=== Setup on the server ===
Let's take a web browser and web server for an example - since that's the most common use of this setup.
# First the web server administrator needs to generate a key pair, roughly the same as what you've been using for SSH (but using different commands).
# The server admin needs to have the public key from that pair signed by a CA which browsers will accept as reliable. There are many such CAs, you can look in your browser's settings to see a full list. Typically people choose the cheapest option that will work in their setup. That's around 60$ a year.
# The admin needs to pay the CA for the service. There's only one free option available which we'll use in this course.
# The CA will use their private key to sign the web server's public key. That will allow people who already have the CA's public key to verify that the web server's public key has not been modified (by anyone other than the people who have access to any trusted CAs private key).
# The server admin can download this signed public key (a.k.a. a certificate) from the CA.
# The server admin will configure the web server to use the server's private key and the CA-signed version of its pair public key for secure communication over HTTPS.
[[File:ServerCA.png|800px|border|center]]
A certificate will always be linked to an FQDN. That mostly makes sense since web browsers connect to a web server using a domain name. Sometimes that's a pain in the neck for the administrator (you'll see why later) and the concept of "wildcard certificate" exists, but I was never able to set one up to work properly.
=== Client communicating with server ===
* certificates, CAs, relationship with DNS
