If you've browsed the web in the past 20 years,
you've interacted with digital certificates,
and maybe without knowing it.
I like to think of a digital certificate,
often called a cert for short, as proof of authenticity.
It's like a government-issued ID card.
It's yours, but was signed by a trusted third party,
and presenting it to others, such as shop clerks,
police, and banks, is accepted as a valid form of ID.
Certs are similar, expect digital, and can be specific to people or machines.
Certificates are based on cryptographic key pairs.
Users and machines can have a private key kept to one's self,
and a public key shared with others.
The cert is the representation of a client's signed public key.
The cert also contains other basic information such as names and dates,
much like a driver's license.
If you are not familiar with how key pairs work,
check out the other Pluralsight courses on PKI.
The presence of these key pairs allows hosts to encrypt and
decrypt traffic to achieve confidentiality.
Creating a professional-grade public key infrastructure is quite
complex and has many integrated components.
In this course,
I won't be covering this and will instead be using self-signed
certificates to demonstrate how FTPS works.
I still want to explain what a production-grade FTPS solution might look like.
You'd have a certificate authority, or CA, somewhere in the network.
This if often a hierarchy of systems used to issue certificates.
Machines or people begin by requesting certificates
using a certificate signing request, or CSR,
containing the device's public key and other personal data.
The CA signs the CSR, which yields a certificate.
Again, think about licensing drivers.
Governments set up small offices where citizens can request ID cards,
then the ID card itself is a trusted authentication source.
Certificates also play a role in encryption as they
contain the device's public key.
A minimal FTPS deployment requires a server-side certificate to
protect the FTP data and signaling channels.
We'll be using a self-signed cert, not a CA-signed cert, for the demonstrations.
More robust FTPS deployments can issue client-side
certificates for authentication,
obviating the need for a username and password combination. For simplicity, we won't be doing this today.