> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SSL and TLS Basics
> Explains SSL/TLS certificate fundamentals, asymmetric and symmetric cryptography, trust establishment, certificate lifecycle, and practical SSH and HTTPS configuration to secure communications.
Hello — this lesson explains the fundamentals of SSL/TLS certificates: what they are, why they matter, and how to configure certificates to secure SSH and HTTPS services. We'll cover the roles of asymmetric and symmetric cryptography, how certificates establish trust, and the lifecycle from key generation to certificate validation.
A certificate (in this context) establishes trust between two parties during a transaction. For example, when a user connects to a web server, TLS certificates make sure the communication is encrypted and that the server is actually who it claims to be.
Why encryption matters
Without secure connectivity, sensitive data (credentials, payment details) could be transmitted in plain text and intercepted by attackers. Encryption protects data in transit by transforming readable data into ciphertext that is useless without the correct key.
Basic cryptography modes
* Symmetric encryption: same key encrypts and decrypts data. Fast and efficient, but requires a secure method to share the key.
* Asymmetric encryption (public-key cryptography): uses a key pair — a private key (kept secret) and a public key (shared). One key encrypts and the other decrypts, removing the need to transmit a shared secret.
Analogy: public key = lock anyone can use to secure a message; private key = the single key that opens what the lock protects. The private key must always remain confidential.
SSH key-based authentication — a practical asymmetric example
Generate an SSH key pair locally and copy the public key to the server:
Example SSH workflow (commands and notes):
```bash theme={null}
# Generate an SSH key pair (RSA example)
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa
# Files created:
# ~/.ssh/id_rsa (private key - keep this secret)
# On the server: append the public key to the user's authorized_keys
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# Use the private key to SSH into the server
ssh -i ~/.ssh/id_rsa user1@server1
```
Consider newer key types: `ed25519` keys are recommended for new SSH key pairs due to stronger security and better performance compared to older RSA keys. Example: `ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519`.
TLS for HTTPS: combining asymmetric + symmetric cryptography
TLS uses both cryptography types:
* Use asymmetric cryptography (public/private keys) to securely agree on a symmetric session key.
* Use symmetric encryption for the bulk of the session because it's faster.
A server typically has a private/public key pair and a certificate containing the server's public key and identifying details. Browsers obtain that certificate when establishing an HTTPS connection.
Example of a server private key (PEM format):
```pem theme={null}
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAABKBgQDkwiLGQAgAN1HpEoLUaqKYiYJIk9wetzotW2/w4nsGhonuWGrT
d7+823xd8FDH+WJLqXsTDkrpKNG3sh67dHRGGipKcEXfZnzT5yDyK/jA6uQvAzl+
I4xNNqtwKDC03uoLpnMEsayPhNtexosfScu1KXeOL6/nTkn9Gc/YoUWzgQIDAQAB
AoGBAOJF6VHCGmfkUGBD0Cc+hzBsq/MQVnYHhUNCM7rIuzocMCkTSi98PqsXS7A7
uhvj4MfIj5WsyIpStwaF6IIxUaP6afrn1KwJ9jZ5bJ9iy0UdYTd3Kk7fOjjkKLK+u
eOk1XibMPLLAXtig7aOvjhg5CmSuhByFc0LRbF8E9l4JOAHBAkEA/ye3prO/ho/8
PhXWc9n+L10cH+FaH4z5peUULNy/xRf1WstV5WCgasvJgtbr7r9p5u4flxS4621/
jNwp8X8sKQJBAOWECwzFLs/GvWZ5H3UV7UoSo6o0QccfKJsQGvGJK0T8rWr8M4vq
h5PDUtoPAcc4Gzgz8BzBbFQ2nmzy10x7t5kCQAQndmL9bDHZqEauflZWhz/oKsWp
tDLtTac4ypJMacbgs/rtcpGQeCwk8zvxGdhCP4w19le0W6phlwEI/YJUCrkCQHgH
wEejb8HV7AOFYMA5AWn1qYYsApaCYxgFKjIbThe9tWv4DXUk6FaM1e3YX1OysfmI
oBBJz7+S+PN9ZL9pDDECQDePUNHDilLyngKMVFj09iRv6YKUc197c4pUseqDr8dx
iyzzypU7eM5pSSDoosysD5iqIcXbdh+j0LKEtGs4vdQ=
-----END RSA PRIVATE KEY-----
```
High-level RSA-style key-exchange flow (illustrative)
1. Browser connects to `https://my-bank.com`.
2. Server sends its certificate (includes the server public key and identity).
3. Browser verifies the certificate (domain, CA signature, validity).
4. Browser encrypts a symmetric session key with the server’s public key and sends it.
5. Server decrypts the session key with its private key.
6. Both use the symmetric key for the session.
Note: Modern TLS commonly uses ephemeral Diffie–Hellman (for example, ECDHE) to provide forward secrecy. In ECDHE, the certificate authenticates the server but the session key is agreed via the key-agreement protocol rather than being directly encrypted with the server's public key.
Never expose private keys. If a private key is leaked, attackers can impersonate your server or decrypt traffic. Store private keys securely (use HSMs, encrypted key storage, or restricted file permissions).
Realistic attack example (phishing + fake certificate)
An attacker could host a replica of your bank’s website and terminate HTTPS with their own certificate. The connection between the browser and the malicious server is encrypted, but the attacker still receives your credentials because you connected to their site. This is why certificate validation and CA trust matter.
How browsers validate certificates
Browsers do more than accept a public key; they validate a digital certificate that contains identifying info (subject/CN and SANs) and a digital signature from a Certificate Authority (CA). Validation steps include:
* Confirm the certificate’s subject or Subject Alternative Names match the URL.
* Verify the certificate’s signature using the issuing CA’s public key.
* Check validity dates and, where applicable, revocation status (CRL/OCSP).
If a certificate is self-signed or signed by an unknown CA, the browser will warn the user.
Certificate Authorities (CAs) and requesting trusted certificates
To get a certificate that browsers trust, use a CA. The CA validates your domain ownership and (depending on the validation level) your organization, then signs a certificate that chains to a trusted root in browser/OS trust stores. Popular public CAs include [DigiCert](https://www.digicert.com), [GlobalSign](https://www.globalsign.com), and others.
Generate a CSR (Certificate Signing Request) with OpenSSL:
```bash theme={null}
# Generate a private key
openssl genrsa -out my-bank.key 2048
# Generate a CSR using that key (non-interactive subject example)
openssl req -new -key my-bank.key -out my-bank.csr -subj "/C=US/ST=CA/O=MyOrg\\, Inc./CN=my-bank.com"
```
Send `my-bank.csr` to the CA. After validation, the CA issues a signed certificate that your users’ browsers will trust because the CA’s root certificate is included in their trust stores.
Private/internal CAs
For internal services you can run a private CA and install the CA root certificate into employee devices so certificates signed by your private CA are trusted within your organization.
TLS handshake summary (simplified)
1. Client connects to `https://example.com`.
2. Server sends its certificate (server public key + identity).
3. Client verifies the certificate (domain match, CA signature, validity).
4. Client and server agree on or exchange a symmetric session key (often via ECDHE for forward secrecy).
5. Client and server use symmetric encryption for application data.
6. The CA’s root public key (in the client trust store) validates the server certificate signature.
Client certificates
TLS can also authenticate clients: during the handshake the server requests a client certificate and validates it. Client certificates are common in high-security or enterprise environments but rare on public consumer websites.
Public Key Infrastructure (PKI)
The ecosystem that manages keys, certificates, issuance, revocation, and trust is called Public Key Infrastructure (PKI). PKI combines technology, processes, and people to maintain secure certificate lifecycles.
Clarifying the lock/key roles
* Signing with a private key allows anyone with the public key to verify authenticity (digital signatures).
* Encrypting with a public key ensures only the private key holder can decrypt (confidentiality).
Keep private keys private — compromise leads to impersonation and decryption risks.
Common naming conventions and file extensions
Use these as a quick reference. Filenames containing the word “key” or extension `.key` usually indicate private keys. Certificates and public keys commonly use `.crt` or `.pem`.
| Resource Type | Typical Extensions | Examples |
| -: | -: | - |
| Certificate / Public Key | `.crt`, `.pem` | `server.crt`, `server.pem`, `client.crt` |
| Private Key | `.key`, `-key.pem` | `server.key`, `server-key.pem`, `client.key` |
Further reading and references
* OpenSSL: [https://www.openssl.org](https://www.openssl.org)
* DigiCert: [https://www.digicert.com](https://www.digicert.com)
* GlobalSign: [https://www.globalsign.com](https://www.globalsign.com)
* TLS overview: [https://datatracker.ietf.org/wg/tls/about/](https://datatracker.ietf.org/wg/tls/about/)
That concludes this lesson on SSL/TLS basics: asymmetric vs symmetric cryptography, certificate authorities, certificate validation in browsers, and practical examples for SSH and HTTPS. Thank you for reading.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.