CresignSys Learn

CresignSys Learn — Lesson 024

Written by

cresignsys

in

Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

From DNS to HTTPS: One Complete Web Request

Difficulty: Intermediate
Prerequisites: Lesson 023 — TCP
Estimated time: 45–60 minutes

Now we connect everything learned so far.

We will follow one request:

https://templates.cresignsys.com

from your computer all the way to your Ubuntu server.

1. The Big Picture

The complete journey is approximately:

Browser
   ↓
DNS
   ↓
IP address
   ↓
Routing
   ↓
TCP
   ↓
TLS
   ↓
HTTPS
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
   ↓
Response
   ↓
Nginx
   ↓
TLS encryption
   ↓
TCP
   ↓
Internet
   ↓
Browser

The important thing is that each layer has a different job.

2. You Type the URL

You enter:

https://templates.cresignsys.com

The browser breaks the URL into concepts such as:

Scheme:
https

Hostname:
templates.cresignsys.com

Port:
443

Because HTTPS conventionally uses port:

443

3. What Does https:// Mean?

The scheme:

https

means approximately:

HTTP
+
TLS

So:

HTTPS = HTTP carried through TLS protection

For traditional HTTPS:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

4. First Problem: Where Is the Server?

Your browser knows:

templates.cresignsys.com

But networking needs an IP address.

Therefore it needs:

DNS

5. DNS Translation

Conceptually:

templates.cresignsys.com
             ↓
            DNS
             ↓
        IP address

Suppose, purely as an example, DNS returns:

203.0.113.10

That is an example address, not your actual server IP.

The browser can now attempt to reach:

203.0.113.10:443

6. DNS Does Not Create the HTTPS Connection

This distinction is important.

DNS only answers the naming question.

DNS:
"What address belongs to this hostname?"

Then networking takes over:

IP:
"How do I reach that address?"

Then TCP:

"How do I establish a reliable transport connection?"

Then TLS:

"How do I establish a secure cryptographic session?"

Then HTTP:

"What web resource do I want?"

7. DNS Caching

The browser or operating system may already know the DNS answer from a cache.

Therefore the browser does not necessarily perform a complete DNS lookup every time you type the URL.

Possible caches include:

Browser cache
 ↓
Operating-system cache
 ↓
Local resolver
 ↓
Recursive DNS resolver
 ↓
Authoritative DNS server

We will study this entire chain in a later lesson.

8. Browser Has the IP

Now suppose the browser has:

Server:
203.0.113.10

and:

Port:
443

The next goal is:

Create TCP connection

9. TCP Connection

The browser’s operating system creates a TCP connection.

Conceptually:

Client
192.0.2.20:53000

       ↓

Server
203.0.113.10:443

Again, these are illustrative addresses.

10. TCP SYN

The client sends:

SYN

Conceptually:

Browser/OS
     │
     │ SYN
     ▼
Server

This is a TCP segment carried inside an IP packet and then a link-layer frame.

11. TCP SYN-ACK

The server responds:

SYN-ACK
Client
  │
  │ SYN
  ▼
Server
  │
  │ SYN-ACK
  ▼
Client

12. TCP ACK

The client sends:

ACK
Client
  │
  │ ACK
  ▼
Server

Now:

TCP connection
=
ESTABLISHED

13. Important Point

At this moment:

TCP = working

But:

HTTPS = not yet established

TLS still needs to happen.

14. TLS Starts

The browser now begins the TLS handshake.

For modern HTTPS connections, the exact handshake details depend on the TLS version and negotiated options. TLS 1.3 is common today.

Conceptually:

TCP established
      ↓
TLS handshake
      ↓
Secure session

15. What Is TLS Trying to Achieve?

TLS provides important security properties including:

Authentication
Confidentiality
Integrity

In simpler language:

Who am I talking to?
 ↓
Can others read the data?
 ↓
Can someone secretly modify the data?

16. Your Let’s Encrypt Certificate Enters Here

You recently installed:

templates.cresignsys.com

with a Let’s Encrypt certificate.

Certbot reported:

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

Private key:
 /etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

These files are now used by your TLS-enabled Nginx configuration.

17. Certificate vs Private Key

This distinction is critical.

You have:

fullchain.pem

and:

privkey.pem

They are not the same thing.

Certificate

Contains the server’s public identity information and public key, together with the CA’s signatures/chain information as applicable.

Private key

Secret cryptographic material that must remain protected on the server.

Conceptually:

Certificate
   ↓
Public information
   ↓
Can be sent to clients

Private key
   ↓
SECRET
   ↓
Must remain on server

18. Why Does the Browser Trust Let’s Encrypt?

Your browser/operating system has a set of trusted:

Root Certificate Authorities

Let’s Encrypt operates a certificate authority hierarchy.

Conceptually:

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

The browser checks the certificate chain against its trusted CA store.

The exact current chain can vary by certificate issuance and client environment.

19. Certificate Identity

Your certificate contains identity information for the domain, typically through:

Subject Alternative Name

For example:

DNS:
templates.cresignsys.com

The browser checks whether the hostname it requested matches the certificate’s valid names.

So:

Browser requests:

templates.cresignsys.com

and checks:

Certificate valid for:
templates.cresignsys.com

20. Certificate Validity Period

Your Certbot output said:

This certificate expires on 2026-11-11.

That means the certificate has a defined validity period.

Certbot also configured automatic renewal.

Conceptually:

Certificate
     ↓
valid
     ↓
renew before expiration
     ↓
new certificate
     ↓
Nginx uses renewed certificate

21. Certificate Does Not Encrypt Everything by Itself

This is a very important correction to a common beginner misunderstanding.

The certificate is not simply:

"the encryption"

Instead, TLS uses certificates and cryptographic protocols to authenticate the server and establish cryptographic keys.

Then symmetric encryption is normally used for the bulk data.

Conceptually:

Certificate
      ↓
Authentication / key establishment
      ↓
Session keys
      ↓
Symmetric encryption
      ↓
HTTPS data

22. Why Not Encrypt Everything With the Public Key?

Public-key cryptography is computationally more expensive than symmetric cryptography for bulk data.

So TLS uses a combination of cryptographic techniques.

Conceptually:

Asymmetric cryptography
        ↓
Securely establish/authenticate key material

Symmetric cryptography
        ↓
Encrypt large amounts of application data

This is called hybrid cryptography.

23. TLS 1.3

Modern TLS commonly uses:

TLS 1.3

It was designed to improve security and reduce unnecessary handshake complexity compared with older TLS versions.

A simplified conceptual handshake:

Client
  │
  │ ClientHello
  ▼
Server
  │
  │ ServerHello + certificate + other handshake data
  ▼
Client
  │
  │ handshake completion
  ▼
Encrypted application data

The exact messages and cryptographic details are more sophisticated than this simplified diagram.

24. ClientHello

The browser sends a:

ClientHello

It communicates information needed to negotiate TLS, including supported protocol capabilities and cryptographic parameters.

Conceptually:

Browser
   │
   │ ClientHello
   ▼
Server

25. ServerHello

The server responds with a:

ServerHello

The server selects compatible cryptographic parameters.

Conceptually:

Client
   │
   │ ClientHello
   ▼
Server
   │
   │ ServerHello
   ▼
Client

26. Server Certificate

The server provides its certificate during the TLS handshake.

Conceptually:

Nginx
 ↓
Certificate
 ↓
Browser

The browser then validates it.

27. What Does the Browser Check?

The browser performs several checks.

Conceptually:

Certificate
 ↓
Is it expired?
 ↓
Does hostname match?
 ↓
Is the chain trusted?
 ↓
Is it cryptographically valid?
 ↓
Is the certificate acceptable under current rules?

If something fails, the browser may display a certificate warning/error.

28. Certificate Chain

Your:

fullchain.pem

normally contains your server certificate together with the intermediate certificate chain needed by clients.

Conceptually:

Root
 ↓
Intermediate
 ↓
Server certificate

The exact chain presented depends on how the certificate was issued and configured.

29. Why fullchain.pem?

Suppose a browser knows/trusts the root but needs the intermediate certificate to build the chain.

The server can provide the necessary chain information.

Conceptually:

Server
 ↓
Server certificate
 ↓
Intermediate certificate
 ↓
Browser
 ↓
Trusted root

This helps the browser build:

Trusted Root
      ↓
Intermediate
      ↓
Server Certificate

30. The Private Key

Your:

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

contains the private key.

It is used by the TLS implementation for cryptographic operations involved in authentication/key establishment.

It should never be publicly exposed.

Do not paste its contents into chat, websites, or support requests.

31. Important Modern TLS Detail

A common beginner explanation says:

“The browser encrypts a session key using the server’s RSA public key.”

That can describe older TLS designs, but it is not the correct general model for modern TLS 1.3.

Modern TLS commonly uses ephemeral Diffie-Hellman key exchange.

Conceptually:

Client ephemeral key
        +
Server ephemeral key
        ↓
Shared secret
        ↓
Session keys

The certificate’s public key authenticates the server’s identity and participates in authentication of the handshake rather than simply encrypting all session keys.

32. Diffie-Hellman Idea

The basic mathematical idea is:

Client secret
      +
Server information
      ↓
Shared secret

Server secret
      +
Client information
      ↓
Same shared secret

Neither side needs to send the final shared secret directly across the network.

This is one of the foundational ideas behind modern secure communications.

33. Why Is This Powerful?

An observer may see:

Client public information
Server public information

but should not be able to efficiently derive the shared secret without the required private/ephemeral secret information.

This relies on hard mathematical problems and secure cryptographic algorithms.

34. Session Keys

Once TLS establishes the required shared secret material, it derives symmetric session keys.

Conceptually:

TLS handshake
      ↓
Shared secret/key material
      ↓
Key derivation
      ↓
Session keys

Then:

HTTP data
 ↓
Symmetric encryption
 ↓
TLS records

35. Now HTTP Can Be Sent

The browser can finally send the HTTP request through the encrypted TLS connection.

Conceptually, the browser wants something like:

GET / HTTP/1.1
Host: templates.cresignsys.com

But on the network:

HTTP request
 ↓
TLS encryption
 ↓
Encrypted TLS records
 ↓
TCP
 ↓
IP
 ↓
Network

So an outside observer cannot simply read the HTTP contents from the network traffic.

36. Nginx Receives It

The encrypted data reaches:

Your server
 ↓
Network interface
 ↓
Linux kernel
 ↓
TCP
 ↓
TLS
 ↓
Nginx

Nginx’s TLS layer decrypts/authenticates the TLS records.

Then Nginx obtains the HTTP request.

37. Nginx Looks at the Hostname

The request contains the hostname:

templates.cresignsys.com

Nginx can use the hostname and its configuration to select the appropriate server block.

This is why one server can host:

site1.example.com
site2.example.com
templates.cresignsys.com

on the same IP address.

This is called:

Name-based virtual hosting

38. Nginx Configuration

You have:

/etc/nginx/sites-enabled/templates.cresignsys.com

Nginx reads its enabled configuration.

Conceptually:

Incoming request
       ↓
Port 443
       ↓
TLS
       ↓
Hostname
       ↓
matching server block
       ↓
templates.cresignsys.com configuration

39. What Does Nginx Do Next?

It determines how to handle the request.

Possibilities:

Static file

or:

PHP request

or:

Proxy request

For WordPress:

Nginx
 ↓
PHP-FPM

is common.

40. Static File Example

Suppose the browser requests:

/favicon.ico

Nginx may simply find:

/storage/websites/templates.cresignsys.com/public/favicon.ico

and return it.

Path:

Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
favicon.ico

PHP isn’t necessary.

41. WordPress Request

Suppose the browser requests:

/

Nginx may route the request to WordPress/PHP.

Conceptually:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress

42. PHP-FPM

PHP-FPM receives the PHP execution request.

Conceptually:

Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP worker

The worker executes WordPress PHP code.

43. WordPress

WordPress loads components such as:

wp-config.php
Core
Theme
Plugins

Then WordPress may need information from the database.

44. MySQL

WordPress communicates with MySQL.

Conceptually:

WordPress
   ↓
Database connection
   ↓
MySQL
   ↓
Database

MySQL retrieves required information.

For example:

Posts
Pages
Settings
Users
Plugin data

45. The Response Travels Back

The result flows backward:

MySQL
 ↓
WordPress
 ↓
PHP-FPM
 ↓
Nginx

Nginx constructs the HTTP response.

For example:

HTTP/1.1 200 OK
Content-Type: text/html

plus the generated HTML.

46. Nginx Does Not Send Plain HTTP Over the Internet

Remember:

HTTP response
 ↓
TLS
 ↓
Encrypted data
 ↓
TCP
 ↓
IP
 ↓
Internet

The browser receives the encrypted TLS records.

47. Browser Decrypts

The browser’s TLS implementation processes the received records:

Encrypted TLS records
       ↓
TLS
       ↓
Plain HTTP response
       ↓
HTML
       ↓
Browser rendering

48. The Page Appears

Eventually:

HTML
 ↓
CSS
 ↓
JavaScript
 ↓
Images
 ↓
Browser rendering
 ↓
Web page

The user sees:

templates.cresignsys.com

49. One Request in One Diagram

Here is the complete conceptual flow:

                    YOUR COMPUTER
                         │
                         ▼
                      Browser
                         │
                         ▼
                        DNS
                         │
                         ▼
                     Server IP
                         │
                         ▼
                       Routing
                         │
                         ▼
                        TCP
                     SYN/ACK
                         │
                         ▼
                        TLS
                  Certificate check
                         │
                         ▼
                    Session keys
                         │
                         ▼
                 Encrypted HTTP
                         │
════════════════════════════════════════════
                     INTERNET
════════════════════════════════════════════
                         │
                         ▼
                  Cloud Network
                         │
                         ▼
                   Ubuntu VPS
                         │
                         ▼
                  Network Interface
                         │
                         ▼
                    Linux Kernel
                         │
                         ▼
                        TCP
                         │
                         ▼
                        TLS
                         │
                         ▼
                       Nginx
                         │
                  ┌──────┴──────┐
                  ▼             ▼
               Static        PHP-FPM
                               │
                               ▼
                            WordPress
                               │
                               ▼
                             MySQL
                               │
                               ▼
                            Response
                               │
                               ▼
                             Nginx
                               │
                               ▼
                         TLS encryption
                               │
                               ▼
                             TCP/IP
                               │
════════════════════════════════════════════
                     INTERNET
════════════════════════════════════════════
                               │
                               ▼
                             Browser
                               │
                               ▼
                         Render webpage

50. Where Your SSL Installation Fits

Your recent Certbot output:

Certificate is saved at:
/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem

Key is saved at:
/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

fits here:

                  Nginx
                    │
                    ▼
               TLS configuration
                │           │
                ▼           ▼
          fullchain.pem   privkey.pem
                │           │
                └─────┬─────┘
                      ▼
                 TLS handshake
                      │
                      ▼
                Secure session
                      │
                      ▼
              Encrypted HTTPS

So the certificate files are part of the server’s TLS configuration.

They don’t independently “run SSL.”

Nginx + its TLS library + Linux networking + certificate/private key + TLS protocol together provide HTTPS.

51. Why Certbot Is Not TLS

Another important distinction:

Let's Encrypt
     ↓
Certificate Authority

and:

Certbot
     ↓
Certificate automation software

and:

Nginx
     ↓
Web server

and:

TLS
     ↓
Security protocol

These are four different things.

52. Their Relationship

Conceptually:

Let's Encrypt
      ↓
issues certificate
      ↓
Certbot obtains/renews it
      ↓
certificate installed/configured
      ↓
Nginx uses certificate
      ↓
TLS handshake
      ↓
HTTPS

This distinction will become extremely important when we study Let’s Encrypt in detail.

53. The Five Technologies You Just Connected

You now have a clear relationship between:

DNS

Name → IP information

IP

Host/network addressing and routing

TCP

Reliable ordered byte stream

TLS

Authentication + confidentiality + integrity

HTTP

Web application protocol

Together:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP

54. One Important Exception: HTTP/3

Do not memorize:

HTTPS always means TCP

That is not universally true.

HTTP/3 uses:

HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP

QUIC integrates TLS 1.3 into its connection establishment.

So:

HTTP/1.1 + TLS → commonly TCP
HTTP/2 + TLS   → commonly TCP
HTTP/3         → QUIC over UDP

We will study this later.

For your current foundational model, continue with:

HTTPS
 ↓
TLS
 ↓
TCP

as the traditional HTTPS architecture.

55. Troubleshooting Using Layers

This lesson gives you a powerful diagnostic method.

If the website doesn’t work:

Layer 1 — DNS

Does the domain resolve?

Layer 2 — IP

Is the destination reachable?

Layer 3 — Routing

Can packets reach the server?

Layer 4 — TCP

Is port 443 accepting connections?

Layer 5 — TLS

Does the TLS handshake succeed?

Layer 6 — HTTP

Does Nginx return a valid HTTP response?

Layer 7 — Application

Does WordPress/PHP/MySQL work?

This is the foundation of real-world troubleshooting.

56. Practical Tests

From your server:

sudo ss -lntp | grep ':443'

This checks whether something is listening on TCP 443.

Check Nginx:

sudo systemctl status nginx

Test Nginx configuration:

sudo nginx -t

Test HTTPS locally:

curl -I https://templates.cresignsys.com

For detailed TLS information:

curl -v https://templates.cresignsys.com

These commands are for inspection/testing; they don’t require you to modify the server.

57. What curl -v Helps Reveal

A verbose HTTPS request can expose the sequence at a useful level:

DNS resolution
 ↓
TCP connection
 ↓
TLS handshake
 ↓
Certificate information
 ↓
HTTP request
 ↓
HTTP response

So curl -v is an excellent bridge between theory and your actual hosting server.

58. Deep Technology Chain

We can now extend the complete chain:

Physical signals
 ↓
Network interface
 ↓
Ethernet / Wi-Fi
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP
 ↓
WordPress
 ↓
MySQL
 ↓
Filesystem
 ↓
Storage

This is essentially the technology stack you are building your hosting knowledge around.

59. The Core Mental Model

Do not memorize hundreds of commands yet.

Understand this:

DOMAIN
  ↓
DNS
  ↓
IP ADDRESS
  ↓
ROUTING
  ↓
PORT
  ↓
TCP
  ↓
TLS
  ↓
HTTP
  ↓
NGINX
  ↓
PHP-FPM
  ↓
WORDPRESS
  ↓
MYSQL
  ↓
FILESYSTEM
  ↓
STORAGE

Once this chain is clear, individual commands become much easier to understand.

Next Lesson — 025

DNS From the Deepest Basics

We will now go backward and study the first step in the journey in much greater depth:

Domain name
 ↓
Hostname
 ↓
DNS
 ↓
DNS hierarchy
 ↓
Root servers
 ↓
TLD servers
 ↓
Authoritative nameservers
 ↓
A record
 ↓
AAAA record
 ↓
CNAME
 ↓
NS
 ↓
MX
 ↓
TXT
 ↓
DNS caching
 ↓
TTL
 ↓
Recursive resolver
 ↓
Your domain
 ↓
templates.cresignsys.com

Then we will examine exactly how your templates.cresignsys.com DNS record points toward your server.

Comments

Leave a Reply

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

More posts