Connectivity TLS Basics

Introduction to SSL/TLS Certificates

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) certificates establish trust and encrypt data between clients and servers. Without them, sensitive information—such as banking credentials—travels in plaintext and can be intercepted.

Symmetric vs. Asymmetric Encryption

Symmetric Encryption

Symmetric encryption uses a single secret key for both encryption and decryption. While efficient, distributing the shared key securely is challenging—if the key is intercepted, the data is compromised.

Asymmetric Encryption

Asymmetric encryption solves the key-distribution problem by using a key pair:

• Private Key: Kept secret by the owner.
• Public Key (Lock): Distributed openly.

Data encrypted with the public key can only be decrypted by the corresponding private key.

Securing SSH Access with Key Pairs

SSH replaces password logins with an asymmetric key pair:

ssh-keygen
# id_rsa     -> private key (keep secure)
# id_rsa.pub -> public key (place on server)

On each target server, append the public key to ~/.ssh/authorized_keys:

cat ~/.ssh/authorized_keys
# ssh-rsa AAAAB3NzaC...KhtUBfoTzlBqRV1NThvOo4opzEwRQo1mWx user1

Connect using your private key:

ssh -i ~/.ssh/id_rsa user1@server1
# Successfully Logged In!

To grant access on multiple servers, copy your public key to each server’s authorized_keys. To onboard other users, they generate their own key pairs and provide you with their .pub file.

HTTPS Key Exchange Process

Web servers combine asymmetric and symmetric encryption to optimize performance:

1. Server generates an RSA key pair.
2. Client (browser) downloads the server’s public key.
3. Browser generates a random symmetric session key.
4. Browser encrypts the session key with the server’s public key.
5. Server decrypts the session key using its private key.
6. Both sides use the symmetric key for bulk data encryption.

Generate the server’s RSA pair with OpenSSL:

openssl genrsa -out my-bank.key 2048
openssl rsa -in my-bank.key -pubout > my-bank.pem

The public key (my-bank.pem) is served to clients; the private key (my-bank.key) remains secure on the server.

Digital Certificates and Trust

A self-generated public key provides no identity proof. Digital certificates bind your public key to your domain, signed by a trusted Certificate Authority (CA).

Certificate:
    Data:
        Serial Number: 420327018966204255
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not After : Feb  9 13:41:28 2020 GMT
        Subject: CN=my-bank.com
        X509v3 Subject Alternative Name:
            DNS:mybank.com, DNS:i-bank.com,
            DNS:we-bank.com
        Subject Public Key Info:
            00:b9:b0:55:24:fb:a4:ef:77:73:7c:9b

Generate a Certificate Signing Request (CSR) and submit it to a CA, such as DigiCert or GlobalSign:

openssl req -new -key my-bank.key -out my-bank.csr \
  -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=my-bank.com"
# my-bank.csr → send to CA for signing

Browser Trust Chain

Browsers ship with a root store of trusted CA public keys. When presented with your signed certificate, the browser:

1. Verifies the CA signature using the trusted root key.
2. Confirms the certificate’s validity period and domain match.
3. Establishes a secure HTTPS session.

Summary

• Symmetric encryption is fast but needs a secure key exchange.
• Asymmetric encryption uses public/private key pairs to exchange secrets safely.
• SSH relies on key pairs for authentication.
• HTTPS uses asymmetric encryption to bootstrap a symmetric session key.
• Digital certificates prove ownership of a public key, validated by CAs.
• Browsers trust certificates based on their embedded root CA list.
• Private CAs work well for internal service authentication.

Mutual TLS (mTLS)

Mutual TLS adds client certificate authentication, requiring both server and client to present valid certificates during the TLS handshake. This strengthens security for APIs and inter-service communication.

Key–Lock Analogy Clarification

Although we talk about a “lock” (public key) and a “key” (private key), either key can encrypt or decrypt. Encrypt with one; decrypt with the other. Private-key encryption is commonly used for digital signatures and identity verification.

Naming Conventions

Always secure private keys and limit their filesystem permissions.

References

• OpenSSL Documentation
• DigiCert
• GlobalSign
• Kubernetes Security