CresignSys Learn

CresignSys Learn — Lesson 038

Written by

cresignsys

in

TLS 1.3 — Deep Cryptographic Basics

We now reach one of the most important parts of your web-hosting system:

What actually happens after TCP connects to port 443 and before the browser receives HTTPS data?

The answer is TLS.

Your current website:

https://templates.cresignsys.com

uses this basic stack:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

This lesson goes from the basic science of cryptography to the actual files created by Let’s Encrypt.

1. What Problem Does TLS Solve?

Imagine you connect to your server over the Internet.

Without encryption:

Browser
   ↓
Internet
   ↓
Server

Someone capable of observing the traffic might potentially read or manipulate application data.

TLS is designed to provide three major properties:

Confidentiality
Integrity
Authentication

2. Confidentiality

Confidentiality means:

Unauthorized observers should not be able to read the protected data.

For example:

Password
 ↓
TLS encryption
 ↓
Internet
 ↓
TLS decryption
 ↓
Server

The network carries encrypted information rather than the original plaintext.

3. Integrity

Integrity means:

Data should not be silently modified without detection.

For example:

Original:
"Pay ₹100"

Attacker tries:
"Pay ₹900"

TLS authentication/integrity mechanisms
 ↓
Modification detected

The exact cryptographic mechanism is provided by authenticated encryption in modern TLS.

4. Authentication

Authentication answers:

Am I really communicating with the server/domain I intended to reach?

For HTTPS, the server presents a certificate.

Conceptually:

templates.cresignsys.com
        ↓
Certificate
        ↓
Certificate Authority
        ↓
Browser trusts CA

5. TLS Is Not the Same as SSL

You may hear:

SSL certificate
SSL
HTTPS certificate
TLS certificate

Historically, SSL was the predecessor.

Modern HTTPS uses:

TLS

Current deployments generally use TLS 1.2 or TLS 1.3.

TLS 1.3 is the modern version we will focus on.

6. HTTPS

HTTPS essentially means:

HTTP
 +
TLS

So:

HTTPS
 ↓
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

for traditional HTTPS over TCP.

7. TCP Happens First

The browser doesn’t start TLS before establishing the underlying TCP connection in the traditional HTTPS/TCP model.

The simplified sequence is:

1. DNS
2. TCP handshake
3. TLS handshake
4. HTTP request

8. TCP Handshake

Previously:

Client                         Server

SYN        ───────────────────►
           ◄────────────────── SYN-ACK
ACK        ───────────────────►

Now TCP is established.

Then:

TLS ClientHello

begins the TLS handshake.

9. TLS ClientHello

The browser sends a:

ClientHello

It tells the server important information about what the client supports.

Conceptually:

Client
 │
 │ ClientHello
 │
 ▼
Server

The ClientHello contains various parameters/extensions.

10. SNI

One particularly important extension is:

SNI — Server Name Indication

The browser can tell the server:

I want:

templates.cresignsys.com

Conceptually:

ClientHello
├── TLS information
├── cryptographic capabilities
└── SNI
      └── templates.cresignsys.com

11. Why SNI Matters to Nginx

Your server may host:

templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

on the same IP.

Nginx needs to know which website the browser wants.

SNI helps it select the appropriate TLS configuration/certificate.

12. Nginx Receives ClientHello

Conceptually:

Internet
 ↓
TCP :443
 ↓
Nginx
 ↓
ClientHello
 ↓
SNI = templates.cresignsys.com

Nginx can then choose the appropriate server configuration.

13. ServerHello

The server responds with:

ServerHello

It selects parameters for the connection.

Conceptually:

Client
 ↓
ClientHello
 ↓
Server
 ↓
ServerHello

The actual TLS 1.3 handshake contains additional messages and cryptographic details.

14. Cryptography

Now we need the foundation.

Cryptography provides mathematical techniques for:

Encryption
Authentication
Integrity
Key exchange
Digital signatures

TLS combines several cryptographic mechanisms rather than using one algorithm for everything.

15. Symmetric Encryption

Symmetric encryption uses the same secret key for encryption and decryption.

Conceptually:

Plaintext
   ↓
[Secret Key]
   ↓
Encryption
   ↓
Ciphertext

Then:

Ciphertext
   ↓
[Same Secret Key]
   ↓
Decryption
   ↓
Plaintext

16. Example

Imagine:

Plaintext:
HELLO

with a secret key:

KEY123

The encryption algorithm produces something like:

Ciphertext:
X7A91...

The exact output is determined by the algorithm and key.

17. Why Symmetric Encryption Is Useful

Once both sides have a shared session key:

Browser
   │
   │ encrypted data
   ▼
Server

symmetric encryption is efficient.

This makes it suitable for protecting large amounts of web traffic.

18. Examples of Symmetric Algorithms

Modern TLS can use authenticated encryption algorithms such as:

AES-128-GCM
AES-256-GCM
ChaCha20-Poly1305

The exact cipher suite negotiated depends on the TLS implementation and supported algorithms.

19. Why Not Use Public-Key Encryption for Everything?

Public-key cryptography is computationally more expensive than symmetric encryption.

Therefore TLS generally uses:

Public-key cryptography
 ↓
establish/authenticate keys

Symmetric cryptography
 ↓
encrypt application traffic

This combination is much more efficient.

20. Asymmetric Cryptography

Asymmetric cryptography uses two related keys:

Public key
Private key

The public key can be distributed.

The private key must remain secret.

21. Public Key

A public key is intended to be shared.

For example:

Certificate
 ↓
contains public key

Browsers can receive the public key as part of the server certificate.

22. Private Key

The private key is secret.

Your Let’s Encrypt installation has a file:

/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

This contains the private key material used by the server’s TLS configuration.

Protect it carefully.

23. Public + Private

Think:

                    SERVER
                       │
          ┌────────────┴────────────┐
          │                         │
     Public Key                 Private Key
          │                         │
     can be shared              SECRET

The certificate contains the public key and identity information.

The private key is kept on the server.

24. Digital Signature

A digital signature allows someone to verify:

This data was signed using the private key corresponding to this public key.

Conceptually:

Data
 ↓
Private key
 ↓
Signature

The verifier uses the public key to validate the signature.

25. Why Signatures Matter to TLS

A certificate authority signs certificates.

Conceptually:

Certificate information
       ↓
CA private key
       ↓
Digital signature

The browser can verify the signature using the CA’s trusted public key.

26. Certificate

A TLS certificate contains information such as:

Domain identities
Public key
Issuer
Validity period
Signature
Extensions

It is much more than simply:

"SSL enabled"

27. Your Certificate

Your certificate was issued for:

templates.cresignsys.com

Certbot reported:

Certificate is saved at:

/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem

and:

Key is saved at:

/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

These two files have very different purposes.

28. fullchain.pem

The:

fullchain.pem

contains the server certificate plus the necessary intermediate certificate chain.

Conceptually:

fullchain.pem
├── Server certificate
└── Intermediate certificate(s)

The exact chain can change depending on the CA’s current issuance architecture.

29. privkey.pem

This contains the server’s private key.

Conceptually:

privkey.pem
       ↓
SECRET
       ↓
Nginx

It should never be made publicly accessible.

30. Certificate vs Private Key

Memorize this distinction:

fullchain.pem
=
certificate chain
=
public information

privkey.pem
=
private key
=
SECRET

31. Why the Browser Needs the Certificate

Suppose you connect to:

templates.cresignsys.com

The browser needs to verify that the server is authorized to represent that domain.

The server presents its certificate.

The certificate says, in effect:

This public key is associated with:
templates.cresignsys.com

and is signed by a trusted certificate authority chain.

32. Certificate Authority

A:

Certificate Authority

or:

CA

is an organization whose certificates/roots are trusted by operating systems and browsers.

Examples include:

Let's Encrypt
DigiCert
GlobalSign
Sectigo

There are many others.

33. Let’s Encrypt

Let’s Encrypt is a Certificate Authority that provides automated certificate issuance.

It uses the:

ACME protocol

for automated certificate management.

34. ACME

ACME means:

Automatic Certificate Management Environment

It allows software such as Certbot to communicate with a CA and automate tasks such as:

Certificate request
Domain validation
Certificate issuance
Renewal

35. Certbot

You used:

Certbot

Certbot is an ACME client commonly used to obtain and manage certificates from Let’s Encrypt.

Conceptually:

Your server
 ↓
Certbot
 ↓
ACME
 ↓
Let's Encrypt

36. Certificate Issuance

The simplified process is:

1. Certbot creates/request materials
        ↓
2. Let's Encrypt asks for domain validation
        ↓
3. Your server/DNS proves control
        ↓
4. Let's Encrypt validates
        ↓
5. Certificate is issued
        ↓
6. Certbot installs it
        ↓
7. Nginx uses it

37. Domain Validation

Let’s Encrypt needs evidence that you control the domain.

It cannot simply issue a certificate to anyone who asks:

google.com

There must be a validation mechanism.

38. HTTP-01 Challenge

One method is:

HTTP-01

The CA asks your server to provide a specific token through HTTP.

Conceptually:

Let's Encrypt
      ↓
http://templates.cresignsys.com/.well-known/acme-challenge/...
      ↓
Nginx/server
      ↓
challenge response

If validation succeeds, the CA knows the requester controls the domain’s web endpoint.

39. DNS-01 Challenge

Another method is:

DNS-01

The CA asks for a special TXT record.

Conceptually:

Let's Encrypt
      ↓
challenge value
      ↓
DNS TXT record
      ↓
Authoritative DNS
      ↓
Let's Encrypt verifies

This is especially useful for wildcard certificates.

40. TLS-ALPN-01

Another ACME validation method is:

TLS-ALPN-01

It performs validation using TLS/ALPN on the TLS endpoint.

Conceptually:

Let's Encrypt
 ↓
TLS connection
 ↓
special ACME validation

You don’t necessarily need to use this method for your current setup.

41. Let’s Encrypt Does Not “Encrypt Your Website”

This is an important conceptual correction.

Let’s Encrypt primarily provides:

Certificate issuance

The actual traffic encryption is performed by:

TLS

using cryptographic keys negotiated between client and server.

So:

Let's Encrypt
 ↓
provides trusted certificate

while:

TLS
 ↓
protects communication

42. TLS 1.3 Key Exchange

TLS 1.3 normally uses modern ephemeral key exchange mechanisms, commonly based on:

ECDHE

Elliptic Curve Diffie-Hellman Ephemeral.

The important idea is:

The client and server can derive a shared secret without sending that secret directly across the network.

43. Diffie-Hellman Concept

Imagine:

Client
   │
   │ public information
   ▼
Server

Both sides perform mathematical operations using:

Private values
+
public parameters

and arrive at the same shared secret.

An observer sees the public exchange but should not be able to feasibly derive the shared secret.

44. Simplified Mathematical Idea

Imagine two people agree publicly on:

G

Client chooses secret:

a

Server chooses secret:

b

Client creates:

G^a

Server creates:

G^b

They exchange these public values.

Then:

Client:
(G^b)^a = G^(ab)

Server:
(G^a)^b = G^(ab)

Both arrive at the same shared secret.

Real cryptographic systems use carefully designed groups and algorithms; this is a conceptual illustration.

45. Why “Ephemeral”?

ECDHE uses temporary per-session key material.

This provides an important property called:

Forward secrecy

If the server’s long-term private key is compromised later, previously captured sessions should not automatically become decryptable, assuming the ephemeral session secrets were properly erased and the cryptographic assumptions hold.

46. Very Important Distinction

Your:

privkey.pem

is the server’s long-term private key associated with the certificate.

It is not simply:

the key used to encrypt every byte of the website

Modern TLS 1.3 uses ephemeral key exchange to establish separate session secrets.

47. Session Keys

After the handshake, both sides derive symmetric session keys.

Conceptually:

ECDHE
 ↓
shared secret
 ↓
TLS key schedule
 ↓
session keys
 ↓
AES-GCM / ChaCha20-Poly1305

48. Application Data

After TLS negotiation:

HTTP
 ↓
TLS record protection
 ↓
TCP
 ↓
IP

For example:

GET /about/

is protected before it travels across the network.

49. Authenticated Encryption

Modern TLS 1.3 uses authenticated encryption algorithms.

Examples:

AES-GCM
ChaCha20-Poly1305

These provide both:

Confidentiality
+
Integrity/authentication of ciphertext

50. AES-GCM

AES is a symmetric encryption algorithm.

GCM means:

Galois/Counter Mode

AES-GCM provides authenticated encryption.

Conceptually:

Plaintext
+
Key
+
Nonce
 ↓
AES-GCM
 ↓
Ciphertext + authentication tag

51. Authentication Tag

The authentication tag helps detect modification.

Suppose an attacker changes encrypted data:

Ciphertext
 ↓
modified
 ↓
TLS verification
 ↓
FAIL

The receiver can detect that the protected data is invalid.

52. ChaCha20-Poly1305

Another modern authenticated-encryption construction is:

ChaCha20-Poly1305

It combines:

ChaCha20
=
encryption

Poly1305
=
authentication

It is widely supported and can perform well, especially on systems without hardware acceleration for AES.

53. TLS Record Layer

Once TLS is established, application data is carried inside TLS records.

Conceptually:

HTTP data
 ↓
TLS record
 ↓
encrypted/authenticated
 ↓
TCP

The exact record format is defined by TLS.

54. TLS 1.3 Handshake — Simplified

A useful conceptual diagram is:

Client                                      Server

ClientHello
  ───────────────────────────────────────►

                                      ServerHello
                                      Certificate
                                      CertificateVerify
                                      Finished
  ◄───────────────────────────────────────

Finished
  ───────────────────────────────────────►

Encrypted Application Data
  ◄──────────────────────────────────────►

The exact message flow can vary with options/extensions.

55. Server Certificate

The server sends its certificate chain.

Conceptually:

Server
 ↓
fullchain.pem
 ↓
Browser

The browser validates the chain.

56. Certificate Chain

A typical chain conceptually looks like:

Root CA
   ↓
Intermediate CA
   ↓
Your server certificate
   ↓
templates.cresignsys.com

The browser generally already trusts the root CA through its trust store.

57. Root Certificate

The root CA certificate is usually installed in:

Operating system trust store

or:

Browser trust store

depending on the environment.

Your server doesn’t generally need to send the root certificate as part of the normal chain.

58. Intermediate Certificate

The intermediate CA is signed by a trusted root or another intermediate.

Conceptually:

Root
 ↓ signs
Intermediate
 ↓ signs
Server certificate

This creates a chain of trust.

59. Why fullchain.pem?

If Nginx sends only the leaf/server certificate and omits a required intermediate, some clients may be unable to build a valid trust chain.

That’s why servers commonly provide:

fullchain.pem

rather than only the leaf certificate.

60. Browser Verification

The browser receives:

Server certificate
+
intermediate certificate(s)

It checks things such as:

Hostname
Validity period
Signature chain
Key usage/extensions
Trust anchor

and other certificate-policy requirements.

61. Hostname Verification

Suppose the certificate is valid for:

templates.cresignsys.com

The browser checks whether the requested hostname matches the certificate’s identity, normally through the:

Subject Alternative Name (SAN)

extension.

62. SAN

SAN means:

Subject Alternative Name

A certificate can contain multiple DNS identities.

For example:

example.com
www.example.com
api.example.com

depending on what was requested and issued.

63. Wildcard Certificate

A certificate could also contain:

*.cresignsys.com

which can cover many one-level subdomains, subject to wildcard matching rules.

For example:

templates.cresignsys.com
shop.cresignsys.com
learn.cresignsys.com

But wildcard matching has specific rules and does not cover arbitrary deeper levels.

64. Your Certificate

Your certificate is specifically associated with:

templates.cresignsys.com

You can inspect it with:

sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem \
-text \
-noout

This displays certificate details.

65. What You Can Inspect

The output contains information such as:

Issuer
Subject
Validity
Public Key
Signature Algorithm
Extensions
Subject Alternative Name

66. Check Expiration

A simpler command:

sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-dates

You can see:

notBefore
notAfter

67. Certificate Files

Your Let’s Encrypt directory commonly contains links/files such as:

/etc/letsencrypt/live/templates.cresignsys.com/
├── cert.pem
├── chain.pem
├── fullchain.pem
└── privkey.pem

These are part of Certbot’s managed certificate structure.

68. Difference Between Them

Conceptually:

cert.pem
=
server/leaf certificate

chain.pem
=
intermediate chain

fullchain.pem
=
cert.pem + chain.pem

privkey.pem
=
private key

69. Nginx Configuration

Nginx commonly uses directives conceptually like:

ssl_certificate /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/templates.cresignsys.com/privkey.pem;

The exact configuration on your server should be checked rather than assumed.

70. What Happens When Nginx Starts?

Conceptually:

Nginx starts
 ↓
reads configuration
 ↓
opens certificate
 ↓
opens private key
 ↓
loads TLS configuration
 ↓
listens on 443

The private key is loaded/used by the TLS implementation under Nginx’s control.

71. Then Browser Connects

Browser
 ↓
TCP 443
 ↓
Nginx
 ↓
ClientHello

Nginx responds with the appropriate TLS handshake information and certificate chain.

72. Certificate Does Not Encrypt the Website by Itself

This is one of the most important concepts.

A certificate doesn’t simply perform:

website
 ↓
encrypted

Instead:

Certificate
 ↓
helps authenticate server identity
 ↓
public-key information
 ↓
TLS handshake
 ↓
session keys
 ↓
symmetric encryption
 ↓
encrypted HTTP

73. Long-Term Key vs Session Key

Keep these separate.

Long-term private key

privkey.pem

Used for server authentication/signature operations associated with the certificate/key.

Session keys

generated during TLS handshake

Used for bulk traffic encryption.

74. Why Session Keys?

Imagine your website sends:

1 GB

of traffic.

Using expensive asymmetric cryptography for every byte would be inefficient.

Instead:

Asymmetric/key exchange
 ↓
small handshake
 ↓
session keys
 ↓
fast symmetric encryption
 ↓
1 GB data

75. This Is Hybrid Cryptography

TLS combines:

Asymmetric cryptography
+
Key exchange
+
Symmetric cryptography
+
Digital signatures
+
Certificate infrastructure

This combination is called a form of:

Hybrid cryptography

76. The Security Chain

For your website:

Let's Encrypt
       ↓
Certificate
       ↓
Public key
       ↓
TLS authentication
       ↓
Key exchange
       ↓
Session keys
       ↓
Authenticated encryption
       ↓
HTTPS

77. Why an Attacker Can’t Simply Read the Traffic

Suppose someone captures packets:

Attacker
 ↓
Internet traffic

They may see:

IP addresses
ports
TLS metadata
encrypted records

but should not be able to derive the session plaintext without breaking the cryptographic protections.

78. What HTTPS Does Not Hide

TLS does not make every piece of network metadata invisible.

Depending on the protocol/version/network environment, observers may still learn information such as:

Source IP
Destination IP
Timing
Traffic volume
Some protocol metadata

Modern technologies such as encrypted ClientHello/ECH aim to protect additional metadata in supported deployments.

79. TLS Doesn’t Replace Firewall

Suppose:

Port 443 blocked

It doesn’t matter that you have a perfect certificate.

The client can’t reach the TLS service.

So:

Firewall
 ↓
must permit traffic

TLS
 ↓
then secures the communication

80. TLS Doesn’t Replace Authentication of Users

A normal HTTPS certificate authenticates the server to the client.

It doesn’t automatically authenticate your website users.

For example:

HTTPS

does not mean:

Only authorized users can log in.

Application authentication is a separate layer.

81. TLS vs Login

TLS
 ↓
secure connection

while:

WordPress login
 ↓
user authentication

are separate concepts.

82. TLS vs Password Hashing

TLS protects passwords while they travel across the network.

Password hashing protects stored passwords.

Conceptually:

Browser
 ↓
TLS
 ↓
Server
 ↓
password hashing
 ↓
database

These solve different problems.

83. TLS vs Encryption at Rest

TLS protects data:

in transit

Disk/database encryption protects data:

at rest

Therefore:

In transit
 ↓
TLS

At rest
 ↓
storage/database encryption

84. Your Server’s Security Layers

Your hosting server potentially has:

Cloud security
 ↓
Ubuntu firewall
 ↓
TCP
 ↓
TLS
 ↓
Nginx
 ↓
WordPress authentication
 ↓
Database permissions
 ↓
Filesystem permissions

Security is layered.

85. TLS Handshake — Big Picture

Memorize this:

Browser
   │
   │ TCP connection
   ▼
Nginx
   │
   │ ClientHello
   ▼
Nginx
   │
   │ ServerHello
   │ Certificate
   │ key-exchange information
   │ authentication
   ▼
Browser
   │
   │ Finished
   ▼
Secure session
   │
   ▼
Encrypted HTTP

The actual TLS 1.3 message structure is more detailed.

86. Your Files in the Process

Now connect the theory directly to your server:

/etc/letsencrypt/live/templates.cresignsys.com/

contains certificate-related material.

Conceptually:

cert.pem
   ↓
server identity certificate

chain.pem
   ↓
intermediate CA chain

fullchain.pem
   ↓
server certificate + intermediate chain

privkey.pem
   ↓
server private key

Nginx uses the relevant files when handling TLS.

87. Why the Private Key Is Critical

If someone obtains:

privkey.pem

they possess the private key associated with that certificate.

This can have serious security implications.

Therefore:

DO NOT

put it under:

public/

and don’t expose it through HTTP.

88. Certificate Expiration

Your certificate currently has an expiration date reported by Certbot.

TLS certificates have finite validity periods.

Certbot therefore schedules renewal.

Conceptually:

Certificate
 ↓
approaching expiration
 ↓
Certbot renewal
 ↓
new certificate
 ↓
Nginx reload/redeployment

89. Renewal

Let’s Encrypt certificates are intentionally short-lived compared with many historical commercial certificate practices.

Automation is therefore important.

Your output showed:

Certbot has set up a scheduled task
to automatically renew this certificate

This means the system has configured automated renewal checks.

90. Renewal Does Not Mean Constant Reissuance

Certbot doesn’t necessarily issue a new certificate every day.

The renewal mechanism checks whether renewal is appropriate.

If renewal isn’t needed:

No new certificate

If renewal is due:

new certificate

is obtained.

91. Test Renewal

A useful administrative command is:

sudo certbot renew --dry-run

This performs a test renewal workflow without replacing the live certificate.

It is useful for verifying that automated renewal is likely to work.

92. Nginx Reload

After certificate changes, Nginx may need to reload its configuration so it uses the updated certificate.

A typical command is:

sudo nginx -t

first, to test configuration.

Then:

sudo systemctl reload nginx

A reload is generally preferable to a full stop/start for ordinary configuration changes because existing connections can be handled more gracefully.

93. Test the Live Certificate

You can use:

openssl s_client \
-connect templates.cresignsys.com:443 \
-servername templates.cresignsys.com

This is an excellent learning tool.

It lets you inspect the TLS handshake and certificate chain.

94. -servername

This option:

-servername templates.cresignsys.com

sends SNI.

This matters when multiple HTTPS websites share the same IP.

95. Certificate Inspection

You can pipe the certificate output:

openssl s_client \
-connect templates.cresignsys.com:443 \
-servername templates.cresignsys.com \
-showcerts

This can show certificates presented by the server.

96. What Browser Shows

When you click the lock/security information in a modern browser, you can inspect information such as:

Certificate
Issuer
Validity
Domain names
Connection security

The exact UI varies by browser.

97. The Most Important Concept

The biggest misconception to remove is:

The certificate is not the thing that directly encrypts all website data.

Instead:

Certificate
 ↓
authenticates server identity
 ↓
supports TLS handshake
 ↓
key agreement
 ↓
session keys
 ↓
symmetric authenticated encryption
 ↓
HTTPS traffic

98. Full TLS Technology Chain

Your website’s HTTPS system can be represented as:

                 HTTPS
                   │
                   ▼
                  HTTP
                   │
                   ▼
                  TLS
                   │
          ┌────────┼─────────┐
          ▼        ▼         ▼
     Certificate  Key       Cipher
     validation   exchange  encryption
          │        │         │
          ▼        ▼         ▼
       Let's      ECDHE     AES-GCM /
       Encrypt              ChaCha20
          │
          ▼
     Certificate
          │
          ▼
      Nginx :443
          │
          ▼
        TCP
          │
          ▼
         IP

99. The Entire Journey

Now connect everything we have learned:

Browser
   │
   ▼
templates.cresignsys.com
   │
   ▼
DNS
   │
   ▼
Public IP
   │
   ▼
Internet routing
   │
   ▼
Oracle Cloud VCN
   │
   ▼
VNIC
   │
   ▼
Firewall/security rules
   │
   ▼
Ubuntu
   │
   ▼
TCP :443
   │
   ▼
TCP handshake
   │
   ▼
TLS 1.3 handshake
   │
   ├── SNI
   ├── Certificate
   ├── Certificate validation
   ├── Key exchange
   └── Session keys
   │
   ▼
Encrypted HTTP
   │
   ▼
Nginx
   │
   ▼
PHP-FPM
   │
   ▼
WordPress
   │
   ├── Filesystem
   └── MySQL

100. What You Should Now Understand

You can now explain these four things separately:

DNS

Where is the server?

TCP

Can we reliably transport bytes?

TLS

Can we authenticate and securely protect the communication?

HTTP

What web request/response are we exchanging?

That separation is fundamental to professional web-server administration.

Lesson 038 Summary

Your Let’s Encrypt installation:

Certbot
 ↓
ACME
 ↓
Let's Encrypt
 ↓
domain validation
 ↓
certificate
 ↓
/etc/letsencrypt/live/templates.cresignsys.com/

produced:

fullchain.pem

and:

privkey.pem

Nginx uses these to participate in TLS.

The actual HTTPS data protection then works approximately as:

Certificate
       ↓
Server authentication
       ↓
TLS 1.3 key exchange
       ↓
Session keys
       ↓
AES-GCM / ChaCha20-Poly1305
       ↓
Encrypted HTTP

Next Lesson — 039

Cryptography From Zero — Keys, Hashes, Encryption and Digital Signatures

Before going further into TLS, we will go down to the mathematical foundations:

Plaintext
 ↓
Encryption
 ↓
Ciphertext

Hash
 ↓
Fixed-length digest

Private key
 ↓
Digital signature
 ↓
Public key
 ↓
Verification

Randomness
 ↓
Keys
 ↓
Security

Then we will connect:

RSA
ECC
ECDSA
ECDHE
SHA-256
AES
ChaCha20
HMAC
AEAD

to the exact roles they play in TLS, Let’s Encrypt, SSH, passwords, WordPress security, and your VPS.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts