mail.google.com
) on it?
the point of a certificate is to prove that a server is the "real"
server for a name. Usually the identity it's trying to prove (the SAN
) is a hostname, like mail.google.com
, but occasionally it's an IP address (like 1.1.1.1
)
you can pay a certificate authority extra for an EV ("extended validation") certificate, but that won't give you better cryptography.
server certificates prove a server's identity (like
mail.google.com
). You can also use client
certificates to prove a client's identity. For example, you could
issue every employee their own client certificate to prove that a request
is coming from a specific employee's laptop).
google.com
certificate, can you trick someone into thinking you're google.com
?
the certificate itself only contains the public key -- it's not secret at all. To actually establish a TLS connection
for google.com
, you also need a separate private
key. The private key is the secret part.
every certificate has an expiration date, usually 3 months to a year after it was issued. This means that even in the worst case where a Bad Guy steals your certificate's private key, it will only be useful to them for a limited amount of time.
with Let's Encrypt, you prove you own the website the certificate is for by setting a DNS record or uploading a file
there are 2 ways to do this:
you can make a "self-signed" TLS certificate on your computer in 2 minutes. But because that certificate isn't signed by a trusted certificate authority, browsers won't accept it.
your browser (or sometimes your OS) has a hardcoded list of trusted certificate authorities.
you can create certificate authority and start signing certificates with it on your laptop in 10 minutes. But no browser will trust your certificate authority unless you explicitly configure the browser to trust it yourself.