SSL and TLS certificates show clients that a web server genuinely belongs to its domain owner and facilitates the secure transmission of information between a client and a web server. They are an integral part of the SSL/TLS handshake process, and are required to establish trust between clients and servers.
Encryption alone is not enough to prevent information from getting into the hands of malicious actors; without properly establishing trust, one could be securely transmitting encrypted information into a web server owned by a malicious actor (who can then decrypt the information and steal your data!).
Contents of SSL and TLS certificates
SSL/TLS certificates typically contain the following information to establish trust:
- The domain name for which the certificate was issued
- The person, organization, or device responsible for the certificate
- The certificate authority (CA) issuing the certificate
- The digital signature of the certificate authority
- Associated subdomains (if any)
- Start and end dates of the certificate’s validity period
This information helps secure a domain from domain spoofing attacks by preventing attackers from creating a fake version of the website. If the certificate cannot be properly validated, browsers will typically return a warning or prevent you from accessing the website.
To facilitate encryption, the SSL/TLS certification also contains the web server's public key.
The public key is a long and random string of numbers that is used in the SSL/TLS handshake process to establish the session keys that will be used for data encryption and decryption during the session.
Self-signed SSL/TLS certificates
There is a special type of TLS/SSL certificate called the self-signed certificate. This certificate is considered self-signed because the certificate isn't issued by a CA, and can be generated by anyone. It contains all the information you'd find in a typical TLS certificate. Self-signed certificates are signed with the website's own private key.
While a self-signed TLS/SSL certificate can serve the same function as a CA-issued certificate, it can't help to establish trust between the domain owner and the web server owner. Trusting self-signed certificates Is usually not a good idea unless you've tested them on your own (non-production) server.
That said, some intranets rely on self-signed certificates because traditional methods of domain validation (DV) aren't available.