Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

4.4.2. Encryption in Transit: TLS, WireGuard, and Certificates

💡 First Principle: Encryption in transit protects data moving between systems from interception and tampering. TLS (Transport Layer Security) establishes an encrypted channel using asymmetric cryptography to exchange a symmetric key, then switches to symmetric encryption for performance. The asymmetric phase also authenticates the server via certificates.

TLS Protocol Versions:
VersionStatusNotes
SSL 2.0/3.0❌ BrokenNever use — known attacks
TLS 1.0/1.1❌ DeprecatedRemoved from modern systems (PCI-DSS, NIST)
TLS 1.2✅ AcceptableStill widely used; configure strong cipher suites
TLS 1.3✅ PreferredFaster handshake, forward secrecy by default
# OpenSSL — key and certificate operations
openssl genrsa -out private.key 4096              # Generate RSA private key
openssl req -new -key private.key -out cert.csr   # Create Certificate Signing Request
openssl x509 -in cert.crt -text -noout            # Inspect certificate details
openssl s_client -connect server:443              # Test TLS connection (interactive)
openssl s_client -connect server:443 -tls1_2      # Force TLS 1.2
openssl verify -CAfile ca.crt server.crt          # Verify cert against CA

# Check TLS version and cipher supported by a server
openssl s_client -connect example.com:443 </dev/null 2>&1 | grep -E "Protocol|Cipher"   # </dev/null so it doesn't hang on stdin
WireGuard — Modern VPN:

WireGuard is a minimal, high-performance VPN built into the Linux kernel. Unlike OpenVPN or IPsec, it uses a single modern cryptographic suite (ChaCha20, Poly1305, Curve25519) with no configuration options — reducing the risk of misconfiguration.

# Install and configure WireGuard
wg genkey | tee private.key | wg pubkey > public.key   # Generate key pair
wg showconf wg0                # Show current interface config
wg show                        # Show active connection status

# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <server_private_key>
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.0.0.2/32

systemctl enable --now wg-quick@wg0
Certificate Management:
# Trusted root certificates
update-ca-trust                 # RHEL — rebuild trusted CA store
update-ca-certificates          # Debian — rebuild trusted CA store

# Add a custom CA
cp myca.crt /etc/pki/ca-trust/source/anchors/   # RHEL
cp myca.crt /usr/local/share/ca-certificates/   # Debian
update-ca-trust / update-ca-certificates         # Rebuild store

# No-cost certificates: Let's Encrypt (certbot) provides free, auto-renewing certs
certbot certonly --standalone -d example.com
certbot renew                   # Renew all expiring certificates
Hashing:
sha256sum file.txt              # SHA-256 hash (integrity verification)
sha256sum -c checksums.txt      # Verify multiple files against checksum file
md5sum file.txt                 # MD5 (deprecated for security; use only for legacy)
openssl dgst -sha256 -hmac "key" file.txt   # HMAC-SHA256 (keyed hash for authentication)

⚠️ Exam Trap: Self-signed certificates provide encryption but NOT authentication — browsers and tools will warn that the certificate is untrusted because no recognized CA vouches for it. The exam distinguishes between "encrypts data in transit" (self-signed can do this) and "provides authenticated, trusted connection" (requires CA-signed certificate). Avoid self-signed certificates in production.

Reflection Question: A web server's certificate was signed by an internal CA that isn't in the OS trust store. Applications connecting to the server get "certificate verify failed" errors even though the certificate is valid. What is the fix, and what command applies it on an Ubuntu system?

Alvin Varughese
Written byAlvin Varughese
Founder18 professional certifications