How does an SSL/TLS certificate work?

A certificate authority verifies a website's identity and issues it a signed certificate. When a browser connects, the server presents this certificate, the browser checks it is valid and trusted, and the two sides then perform a handshake to agree on a shared session key. All further traffic is encrypted with that key, so no one in between can read it.

What is the difference between SSL and TLS?

TLS is the modern successor to SSL. SSL version 3 was the last SSL release and is now deprecated due to security flaws, replaced by TLS. People still say SSL out of habit, but today's certificates and connections use TLS, with TLS 1.3 being the current version.

What is a Certificate Signing Request (CSR)?

A CSR is a request the site owner generates and sends to a certificate authority. It contains identifying information such as the domain name and the site's public key. The CA uses it to verify the requester and issue the certificate.

What happens during the TLS handshake?

The server presents its certificate, the client verifies it is valid, unexpired, trusted, and issued for the right domain, and then the two sides agree on a shared session key. After the handshake, all data is encrypted with that key.

What is the current version of TLS?

TLS 1.3 is the most current and most secure widely used version. It is faster and drops older insecure options compared with TLS 1.2. SSL 3.0 and earlier are deprecated and should not be used.

How SSL/TLS Certificates Work: The Process Explained

HTTPS padlock representing an SSL/TLS secured connection

SSL and TLS certificates are the foundation of secure communication on the internet. They encrypt the data that moves between a browser and a server, and they prove that the server really is who it claims to be. This page explains how an SSL/TLS certificate works, step by step, from the moment a certificate is requested to the encrypted connection a visitor sees as the padlock in their browser.

A quick note on names: SSL certificates are now really TLS certificates. The last version of SSL, SSL 3.0, was deprecated because of security vulnerabilities, and TLS replaced it. The current version in wide use is TLS 1.3. People still say “SSL” out of habit, but the technology underneath is TLS.

How SSL/TLS certificates work: the short version

A certificate authority verifies a website’s identity and issues it a digitally signed certificate. When your browser connects to that site, the server presents the certificate, your browser checks that it is valid and trusted, and the two sides run a handshake to agree on a secret session key. Everything after that is encrypted with that key. The steps below break this down.

Certificate request (the CSR)

To get a certificate, the site owner generates a Certificate Signing Request (CSR). The CSR contains information about the website’s identity, such as its domain name and its public key. The owner sends the CSR to a Certificate Authority (CA), which is a trusted third party that issues certificates.

Verification

The CA verifies the legitimacy of the requester before issuing anything. Depending on the certificate type, these checks can include confirming domain ownership, checking the requester’s organization details, and validating their identity. Once the CA is satisfied, it proceeds to issue the certificate.

Certificate issuance

The CA creates the SSL/TLS certificate and digitally signs it using the CA’s own private key. That signature is what lets browsers later confirm the certificate is genuine and was issued by a trusted authority. The CA sends the finished certificate back to the website owner.

Certificate installation

The website owner installs the certificate on their web server, typically by adding the certificate and its key to the server configuration. Once installed, the server can offer secure HTTPS connections.

The SSL/TLS handshake

The handshake begins when a visitor’s browser connects to the secured site. It goes like this:

The server presents its SSL/TLS certificate to the client.
The client, usually a web browser, checks that the certificate is valid and unexpired, trusted by a known CA, and issued for the domain being visited.
If those checks pass, the client generates a random symmetric encryption key called the session key.

Key exchange

The client encrypts the session key using the public key from the server’s certificate and sends it to the server. Only the server’s matching private key can decrypt it, so the session key arrives safely even over an untrusted network.

Encryption and secure communication

Now both sides hold the same session key. They use it with symmetric encryption to protect everything that follows. All data exchanged between client and server is encrypted and decrypted with this shared key, so anyone intercepting the traffic sees only ciphertext. This is what protects confidentiality and integrity for the rest of the session.

To sum up, SSL/TLS certificates do two jobs at once: they verify that a website is authentic, and they set up encryption so the data between a user’s device and the server stays private and tamper-proof.

TLS vs SSL: what’s the difference? — how the two protocols relate and why TLS replaced SSL
How traffic flows in Kubernetes — where TLS termination fits in a cluster