Skip to main content
This lesson covers the essential concepts behind TLS certificates: what they are, why they matter, and how they secure SSH and HTTPS traffic. You’ll learn the differences between symmetric and asymmetric encryption, how certificates establish trust, and the role of Certificate Authorities (CAs) and Certificate Signing Requests (CSRs). Why TLS matters
  • TLS protects data in transit so sensitive information (passwords, session tokens, financial data) cannot be read by eavesdroppers.
  • Without encryption, credentials typed into an online banking app would travel as plaintext across the network and could be intercepted.
Symmetric vs Asymmetric Encryption Symmetric encryption
  • Uses a single shared key to both encrypt and decrypt data.
  • Efficient for bulk data transfer, but secure key distribution is a challenge: if the shared key is intercepted, confidentiality is broken.
A diagram showing a user accessing an online banking webpage and connecting to a web server with a link labeled "Symmetric Encryption." Key icons and sample (obfuscated) keys are shown above to represent the shared encryption.
Asymmetric encryption
  • Uses a key pair: a private key (kept secret) and a public key (shared freely).
  • Anything encrypted with the public key can only be decrypted by the corresponding private key.
  • Solves the key-distribution problem: you can securely exchange symmetric keys over an insecure channel and then use symmetric encryption for the session.
A diagram labeled "Asymmetric Encryption" showing a connected Public Lock and Private Key. Below it is a small credentials box listing "User: John" and "Password: Pass123."
Practical example — SSH
  • SSH uses asymmetric key pairs for authentication. You generate a key pair locally and place the public key on the server (e.g., in ~/.ssh/authorized_keys).
  • The private key remains on your machine and authenticates you to the server.
Keep your private keys safe. If someone gains access to your private key, they can authenticate as you.
Example SSH commands and flow:
You can reuse the same public key across multiple servers. Other users generate their own key pairs and you add their public keys to grant access. HTTPS key exchange and TLS handshake (summary)
  • Web servers present an asymmetric key pair (public key inside a certificate).
  • The client verifies the certificate and negotiates a symmetric key:
    • Either by encrypting a symmetric key with the server’s public key (RSA key transport), or
    • By performing an ephemeral Diffie-Hellman key exchange (e.g., ECDHE) that both authenticates (via the server’s certificate) and produces a shared symmetric key.
  • Both sides then use the symmetric key for efficient encrypted communication.
  • Modern TLS prefers ephemeral Diffie-Hellman (ECDHE) because it provides forward secrecy.
TLS handshake — simplified steps
  1. Client connects and requests a secure session.
  2. Server responds with its certificate (contains the server’s public key and identifying info).
  3. Client validates the certificate chain and domain names (SANs).
  4. Client and server perform the agreed key-exchange (RSA or ECDHE) to derive a symmetric session key.
  5. All subsequent data is encrypted with the symmetric key.
Why certificate signatures matter
  • Anyone can generate a certificate that claims to be for any domain — but the browser must trust who signed it.
  • Browsers and operating systems contain a trust store of CA public keys. If a certificate is signed by a trusted CA, the browser accepts it; otherwise, the user sees a warning.
A simple infographic showing a user visiting "my-bank.com" whose login (User: John, Password: Pass123) is intercepted by a hacker server, resulting in a "You have been hacked!" message. It illustrates a phishing or man-in-the-middle style cyberattack.
Trust chain and Certificate Authorities (CAs)
  • Self-signed certificates: created and signed by the same entity; not trusted by browsers by default.
  • Public CAs (e.g., Symantec, DigiCert, GlobalSign) sign certificates for public-facing sites.
  • Private/internal CAs: used inside organizations; the organization’s CA public certificate must be distributed to clients for them to trust issued certificates.
Browser warnings
  • When a certificate is invalid, expired, or signed by an untrusted CA, browsers display warnings such as “Your connection is not private.”
The image shows a browser security warning saying “Your connection is not private” for https://my-bank.com with a “Not secure” padlock indicator. Beside it is a decorative certificate mockup labeled “CERTIFICATE” and “MY-BANK.COM,” suggesting an SSL/certificate issue.
Getting a trusted certificate — CSR + CA
  • Generate a private key and a Certificate Signing Request (CSR).
  • Submit the CSR to a CA. The CA verifies identity/domain ownership and signs the CSR to issue a certificate.
  • The browser trusts the certificate because it trusts the CA’s public key in its trust store.
OpenSSL example: create a private key and CSR
Example certificate contents (truncated):
CA trust and issuance
  • The CA signs the certificate using the CA’s private key.
  • Browsers validate that the server certificate is signed by a trusted CA (or by a chain leading to a trusted CA) and that the certificate is valid for the requested domain.
An infographic about SSL/TLS certificates and certificate authorities, showing logos for Symantec, GlobalSign and DigiCert, a server/private CA icon, and a printed certificate for "my-bank.com." The left side shows an online banking webpage with the browser address bar flagged "Not secure."
Common certificate and key file naming Core concepts summary
  • Use asymmetric (public/private) keys to authenticate and securely exchange symmetric session keys.
  • Symmetric encryption is used for fast bulk encryption after a secure key exchange.
  • SSH uses asymmetric keypairs for authentication (private key kept private; public key on servers).
  • HTTPS uses server certificates (public key in a signed certificate) so clients can verify server identity and negotiate a symmetric key.
  • CAs sign certificates with a private key; clients trust certificates signed by CAs in their trust store.
  • The ecosystem of keys, certificates, CAs, issuance, and validation is called Public Key Infrastructure (PKI).
Mutual TLS (mTLS)
  • Servers can require client certificates to authenticate clients (client must present a cert signed by a CA trusted by the server).
  • mTLS is common in internal/enterprise systems and APIs for strong mutual authentication, but rare for public websites.
Clarifying signing vs encryption
  • Public/private keys are mathematically linked.
  • Confidentiality: encrypt with recipient’s public key so only the recipient can decrypt with their private key.
  • Authentication and integrity: sign (hash) data with your private key; recipients verify the signature using your public key.
  • Signing is not the same as encrypting an entire message with a private key — do not share private keys.
File naming conventions recap
A dark-blue infographic comparing public certificates (left) and private key files (right), showing example filenames (.crt/.pem vs .key) with a lock icon for public and a key icon for private. A small legend and KodeKloud copyright appear at the bottom.
Final notes
  • Protect private keys at all costs — compromise of a private key breaks authentication and can expose encrypted traffic.
If an attacker obtains your private key, they can impersonate your server or decrypt previously intercepted sessions (if forward secrecy is not used). Use secure key storage and rotate keys if suspected compromised.
Further reading and references Thank you for reading — this covers the fundamentals of TLS, certificates, and how they secure SSH and HTTPS communications.

Watch Video