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):
# 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_keyscat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys# Use the private key to SSH into the serverssh -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):
Server sends its certificate (includes the server public key and identity).
Browser verifies the certificate (domain, CA signature, validity).
Browser encrypts a symmetric session key with the server’s public key and sends it.
Server decrypts the session key with its private key.
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, GlobalSign, and others.Generate a CSR (Certificate Signing Request) with OpenSSL:
# Generate a private keyopenssl 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)
Client connects to https://example.com.
Server sends its certificate (server public key + identity).
Client verifies the certificate (domain match, CA signature, validity).
Client and server agree on or exchange a symmetric session key (often via ECDHE for forward secrecy).
Client and server use symmetric encryption for application data.
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.
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.
