A few quick answers about what SSL/TLS certificates are
Why do we use SSL certificates?
SSL/TLS certificates make it possible to add two important capabilities to online communication.
- Sender identity
If the certificate contains the name of the party you are communicating with and your machine trusts the certificate issuer, your machine trusts that you are talking to the correct web server. In addition, data you receive is signed with the certificate so it cannot be tampered with during transit. - Data confidentiality
Two parties who have never met before can establish a secure channel over a very insecure channel (such as the internet), without anyone listening on the insecure line being able to eavesdrop on the secure one.
It is possible today to establish encryption without the TLS certificate, but it is still the only thing we can use to verify that the server we are talking to is the right one.
Why would the internet not work without SSL/TLS?
The only available form of encryption would be symmetric encryption, meaning that parties who need to communicate securely must have a secret code beforehand, one that is not communicated over an insecure channel such as the internet or telephone.
You would need to visit the bank, the post office, the web shop, your workplace, and so on, to agree on a code with each one before communicating with them online.
You would not be able to communicate securely with anyone else, because any attempt to agree on a code over the internet could be intercepted. And even if you exchange a code securely with the other party, you cannot be sure you are actually talking to the right people, or to someone sitting between you and them (man-in-the-middle).
That means no creating accounts on websites, no shopping on eBay, Amazon, or Facebook, and no entering credit card information online.
Everyone would be able to eavesdrop, obtain each other's codes, and worse, impersonate each other.
What is in an SSL/TLS certificate?
An SSL/TLS certificate always consists at minimum of a private key known only to the owner and a public key accessible to everyone.
In addition, the certificate can contain information such as:
- Who the certificate belongs to, e.g. FairSSL ApS or Sole Viktor
- Who can communicate using the certificate, e.g. www.fairssl.com or info@fairssl.com
- Who created the certificate and their signature, e.g. GlobalSign with a SHA256 signature
- Where to obtain a copy of the public certificate (public key) that created this certificate, typically a URL or local file path
- Where to check if the certificate has been revoked (CRL/OCSP)
- What purposes the certificate may be used for, e.g. email data encryption, code signing, server communication, client communication, or creating new certificates
- When the certificate is valid from and until
Why do SSL certificates have an expiration date?
Certificates expire partly to reduce the time a potential attacker has to break the key.
It also forces faster replacement of certificates that may contain flaws discovered only later.
It potentially reduces the time a lost or stolen certificate can be used, although this is more theoretical, since abuse over just a few hours can be catastrophic in itself.
What is the difference between a certificate issued by a trusted CA, an internal CA, or a self-signed certificate?
- Trusted public CA
A certificate issued by a trusted CA, such as Comodo, is signed by a certificate created by a trusted root certificate that is pre-installed in clients by manufacturers such as Nokia, Microsoft, Sony, and others. The trusted CA is typically required to follow a long list of strict rules, such as those specified by CAB/Forum. - Internal CA
Works the same way: the certificate is issued by another intermediate or root certificate, but the root certificate must be installed on every client PC or mobile device it needs to work with, for example by the company's IT department. - Self-signed certificate
The certificate is only trusted if a copy is installed on every client.
What is the relationship between HTTP, HTTPS, and certificates?
HTTP is a protocol that defines how a browser and web server communicate.
HTTPS adds an SSL/TLS layer that wraps around HTTP and secures the communication.
The browser uses SSL/TLS to verify:
- That the certificate is signed by a chain of certificates ending with a root certificate installed on the client
- That the certificate is still valid and has not been revoked
- That the certificate contains a SAN DNS/IP name matching the server being communicated with
- That a shared secret can be established between browser and web server for encrypting the communication
Is there a connection between certificates and sending encrypted data?
SSL/TLS certificates are used in encryption by exchanging a random key that will subsequently be used to encrypt the actual data, encrypted using the public key in the certificate.
In asymmetric encryption, the client uses the certificate's public key to encrypt a random secret, which only the server can decrypt using its private key.
In simplified terms, the following steps occur in a browser:
- The browser client uses the web server's public key (which is available to everyone) to encrypt a secret it has generated.
- The web server then decrypts the secret using its private key (which only it possesses).
- Now both the web server and the browser client share the same secret, without anyone else being able to understand or intercept it.
- They then switch to faster symmetric encryption, using the same secret to encrypt and decrypt the information.
Asymmetric encryption with the SSL/TLS certificate makes it possible to deliver a secret to the web server that only it can read. After that, the certificate is not used for encryption (secure email communication is the exception); instead, faster symmetric encryption takes over.
Why is online encryption written as SSL, TLS, or SSL/TLS?
It has become common to call online encryption SSL (Secure Sockets Layer), since it was the first protocol widely used for online encryption. However, it is the TLS protocol (Transport Layer Security), an evolution of SSL 3.0, that is used today.