Last modified: April 27, 2026
This article is written in: 🇺🇸
Transport Layer Security, commonly abbreviated as TLS, is a cryptographic protocol that protects data transmitted over computer networks. It is the modern successor to SSL, or Secure Sockets Layer. Although people still often say “SSL certificate” or “SSL connection,” most modern secure web traffic actually uses TLS.
TLS protects communication between two parties, such as a browser and a web server. It helps ensure that data cannot easily be intercepted, read, modified, or impersonated by attackers while it travels across the network.
TLS is used by HTTPS websites, APIs, email protocols, VPNs, messaging systems, service-to-service communication, and many other networked applications. It provides three core protections: confidentiality, integrity, and authentication.
TLS started as an improved replacement for SSL. SSL had several weaknesses and is now considered obsolete. Modern browsers, servers, and security standards use TLS instead.
The phrase “SSL certificate” is still common because it became popular before TLS replaced SSL. In practice, that certificate is used for TLS connections.
Example terminology:
Common phrase: SSL certificate
Modern technical meaning: TLS certificateExample output:
{
"oldProtocol": "SSL",
"modernProtocol": "TLS",
"recommendedVersions": ["TLS 1.2", "TLS 1.3"]
}Older protocols such as SSLv2, SSLv3, TLS 1.0, and TLS 1.1 should generally be disabled in production. Modern deployments should prefer TLS 1.3 and support TLS 1.2 only when needed for compatibility.
TLS relies on encryption, identity verification, and integrity checks.
Encryption protects the contents of the communication. If an attacker intercepts the traffic, they should see unreadable encrypted data rather than passwords, tokens, payment details, or private messages.
Identity verification helps the client confirm that it is talking to the correct server. This is done through digital certificates issued by certificate authorities.
Integrity ensures that data cannot be silently changed in transit. If an attacker modifies encrypted traffic, the receiving side should detect that the data has been tampered with.
After the TLS handshake finishes, the client and server share session keys. These keys are used to encrypt and decrypt the actual application data, such as HTTP requests and responses.
Example protected exchange:
Browser requests https://example.com/login
TLS verifies the server certificate
TLS establishes encrypted session keys
Login request is sent through encrypted channelExample output:
{
"connection": "secure",
"encryption": "enabled",
"serverIdentityVerified": true,
"dataIntegrityProtected": true
}When a client accesses a server over HTTPS, a TLS handshake happens before normal application data is exchanged. The handshake negotiates protocol versions, selects cryptographic algorithms, verifies the certificate, and establishes shared session keys.
Client (Browser) Server (Website)
| |
| 1. ClientHello ---------------------> |
| Supported TLS versions, ciphers |
| |
| <--------------- 2. ServerHello ------|
| Chosen cipher, certificate |
| |
| 3. Certificate Verification |
| Validate server certificate |
| |
| 4. Key Exchange --------------------> |
| Exchange key material |
| |
| <------------ 5. Server Key Exchange |
| Both generate session keys |
| |
| 6. Secure Communication --------------|
| Data encrypted with session keys |
| |
| <------------- Encrypted Data --------|
| Server responses also encrypted |The exact handshake differs between TLS 1.2 and TLS 1.3, but the high-level purpose is the same: agree on secure settings and establish encryption keys.
Example handshake summary:
{
"clientHello": "client lists supported TLS versions and cipher suites",
"serverHello": "server selects secure options and sends certificate",
"certificateVerification": "client checks certificate validity",
"keyExchange": "client and server derive shared session keys",
"secureChannel": "application data is encrypted"
}Once the handshake completes, normal HTTP traffic can flow through the encrypted TLS tunnel.
Example encrypted application request:
GET /account HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...Example protected response:
{
"accountId": "acct-123",
"status": "active"
}The application sees readable HTTP data after TLS decryption, but on the network the data is encrypted.
A TLS certificate proves the identity of a server. It contains information such as the domain name, public key, issuer, validity period, and digital signature.
Certificate Authorities, or CAs, issue certificates after verifying that the requester controls the domain. Some certificates also include organization details, depending on the certificate type.
When a browser connects to a website, it checks the server’s certificate. The browser verifies that the certificate is signed by a trusted CA, has not expired, matches the requested domain, and has not been revoked or otherwise invalidated.
Example certificate fields:
{
"subject": "mysite.example.com",
"issuer": "Example Certificate Authority",
"validFrom": "2026-01-01",
"validTo": "2026-04-01",
"publicKey": "included",
"signature": "signed_by_ca"
}Example validation output:
{
"domainMatches": true,
"certificateExpired": false,
"issuerTrusted": true,
"connectionTrusted": true
}To trust a certificate, the client checks whether the issuing CA or a parent CA exists in its trust store. Browsers and operating systems include trust stores with many recognized certificate authorities.
If the certificate is invalid, the browser may show a warning.
Example invalid certificate output:
{
"connectionTrusted": false,
"reason": "certificate expired"
}TLS is essential because internet traffic often travels through many networks before reaching its destination. Without encryption, intermediaries may be able to inspect or modify the data.
TLS protects sensitive information such as usernames, passwords, payment details, session cookies, API keys, health information, private messages, and business data.
TLS also helps prevent man-in-the-middle attacks. In such an attack, an attacker tries to place themselves between the client and server. Certificate validation helps the client verify that it is communicating with the intended server, not an imposter.
Example without TLS:
User sends password over HTTP
Attacker on network captures traffic
Password is visible in plaintextExample with TLS:
User sends password over HTTPS
Attacker captures encrypted traffic
Password is not readableExample output:
{
"httpRisk": "credentials may be exposed",
"httpsProtection": "traffic is encrypted and server identity is verified"
}HTTPS is also expected by users, browsers, APIs, and many platform features. Browsers may label non-HTTPS pages as insecure, especially when forms or sensitive data are involved.
TLS has evolved over time. Older versions were designed for earlier internet security needs and now contain weaknesses or outdated cryptographic choices. Modern systems should use TLS 1.2 or TLS 1.3.
TLS 1.2 was released in 2008 and became the long-standing standard for secure web communication. It supports stronger hashing, authenticated encryption modes, and better negotiation of signature algorithms compared with older versions.
TLS 1.2 can still be secure when configured properly. The key is to disable weak algorithms and use modern cipher suites.
Example secure TLS 1.2 configuration idea:
Allowed:
- TLS 1.2
- ECDHE key exchange
- AES-GCM or ChaCha20-Poly1305
- SHA-256 or stronger
Disabled:
- SSLv2
- SSLv3
- TLS 1.0
- TLS 1.1
- RC4
- 3DESExample output:
{
"protocol": "TLS 1.2",
"status": "secure_if_configured_with_modern_ciphers"
}TLS 1.2 has remained widely deployed because many older clients and systems still support it. However, it requires careful configuration to avoid legacy weaknesses.
TLS 1.3 was finalized in 2018 and simplified many parts of the protocol. It removed obsolete features and reduced the number of round trips needed to establish a secure connection.
Key improvements include:
Example TLS 1.3 output:
{
"protocol": "TLS 1.3",
"handshake": "simplified",
"forwardSecrecy": "mandatory",
"legacyCryptography": "removed"
}TLS 1.3 is generally preferred for modern systems because it is faster and harder to misconfigure than older versions.
Upgrading to TLS 1.3 can improve both security and performance. However, the transition should be tested carefully, especially if the system supports older clients, embedded devices, legacy Java runtimes, or enterprise integrations.
A practical migration plan may include:
Example compatibility output:
{
"serverSupportsTls13": true,
"tls12FallbackEnabled": true,
"legacyClientFailures": 3,
"migrationStatus": "monitoring"
}Keeping TLS 1.2 temporarily can be useful for compatibility, but older protocols should remain disabled.
Deploying TLS involves obtaining a certificate, installing it on the server or proxy, enforcing HTTPS, and testing the configuration.
In many production systems, TLS is terminated at a reverse proxy, load balancer, API gateway, or CDN. The backend application may receive traffic from that internal component. Depending on security needs, internal traffic may also use TLS or mutual TLS.
A TLS setup begins with a private key and a certificate. In many cases, the process looks like this:
Example OpenSSL command:
openssl req -newkey rsa:2048 -nodes -keyout mysite.key -out mysite.csrExample output files:
mysite.key # private key
mysite.csr # certificate signing requestThe private key must be protected carefully. It should not be committed to source control, copied into public images, emailed, or exposed in logs.
Example private key protection:
Owner: root
Permissions: 600
Location: /etc/ssl/private/mysite.keyExample output:
{
"privateKeyStoredSecurely": true,
"csrReadyForCA": true
}Many teams use automated certificate tools such as ACME clients to request and renew certificates.
Once the CA returns the certificate, place it on the server along with the private key. The exact configuration depends on the web server or proxy.
Example Nginx snippet:
server {
listen 443 ssl;
server_name mysite.example.com;
ssl_certificate /etc/ssl/certs/mysite.crt;
ssl_certificate_key /etc/ssl/private/mysite.key;
# TLS 1.2 and 1.3 only
ssl_protocols TLSv1.2 TLSv1.3;
# Example placeholder for secure TLS 1.2 ciphers
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:...";
root /var/www/mysite;
}Example configuration test:
nginx -tExample output:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successfulAfter reloading Nginx, requests to https://mysite.example.com/ are protected by TLS.
TLS only helps if users actually connect over HTTPS. Sites should redirect HTTP traffic to HTTPS and avoid serving sensitive content over plain HTTP.
Example Nginx HTTP-to-HTTPS redirect:
server {
listen 80;
server_name mysite.example.com;
return 301 https://mysite.example.com$request_uri;
}Example HTTP request:
GET /login HTTP/1.1
Host: mysite.example.comExample redirect response:
HTTP/1.1 301 Moved Permanently
Location: https://mysite.example.com/loginThis ensures that users who type the HTTP address are redirected to the secure HTTPS version.
HSTS can further strengthen this behavior:
Strict-Transport-Security: max-age=31536000; includeSubDomainsExample output:
{
"httpsRedirect": "enabled",
"hsts": "enabled",
"result": "browsers prefer secure connections"
}HSTS should be deployed carefully because it tells browsers to force HTTPS for the configured period.
After configuring TLS, test the server. Testing should confirm that the certificate is valid, the domain matches, old protocols are disabled, modern cipher suites are enabled, and certificate chains are complete.
Example test command:
openssl s_client -connect mysite.example.com:443 -servername mysite.example.comExample output summary:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)Example monitoring output:
{
"certificateValid": true,
"protocol": "TLS 1.3",
"certificateExpiresInDays": 62,
"weakProtocolsEnabled": false
}External TLS checking tools can provide detailed reports about certificate chains, cipher suites, protocol support, and known configuration issues.
Deploying TLS effectively requires careful configuration and ongoing maintenance. A site can have a certificate but still be weakly configured if it supports obsolete protocols or unsafe cipher suites.
Prefer modern TLS versions Use TLS 1.3 where possible and TLS 1.2 as fallback when needed.
Disable insecure protocols Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1 unless a strict legacy requirement exists.
Use strong cipher suites Avoid obsolete ciphers such as RC4 and 3DES.
Protect private keys Store private keys in secure directories with limited permissions.
Use HSTS carefully HSTS helps browsers avoid insecure HTTP connections.
Renew certificates promptly Monitor expiration dates and automate renewal when possible.
Monitor handshake failures TLS errors in logs may reveal expired certificates, misconfigured chains, unsupported clients, or active probing.
Use secure internal transport when needed If backend traffic contains sensitive data, consider TLS or mutual TLS between services, not only at the public edge.
Example best-practice status:
{
"tls13Enabled": true,
"tls12Fallback": true,
"sslDisabled": true,
"hstsEnabled": true,
"certificateAutoRenewal": true,
"privateKeyPermissions": "restricted"
}TLS is one of the most important protections for modern networked systems. When configured well, it protects confidentiality, verifies server identity, and helps prevent tampering in transit.