Category: Uncategorized

CresignSys Learn — Lesson 043
Linux Filesystem & Permissions — The Foundation of Web Hosting

We now move below Nginx and PHP-FPM.

A web server ultimately depends on the Linux operating system being able to answer:

Who is allowed to read, write, execute, create, delete, and access this file?

For your hosting system, this is fundamental.

1. The Hosting Stack So Far

We have reached:
```
Browser
   ↓
DNS
   ↓
IP
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
```
Now go one layer deeper:
```
PHP-FPM
   ↓
Linux filesystem
   ↓
Storage
```
2. Linux Is a Filesystem-Centered System

Linux represents many things through files or filesystem interfaces.

You will constantly work with:
```
/
├── etc/
├── var/
├── home/
├── usr/
├── run/
├── tmp/
└── storage/
```
The first:
```
/
```
is called:

Root directory

It is the top of the Linux filesystem hierarchy.

3. / Is Not /root

These are completely different.
```
/
```
means:

filesystem root

while:
```
/root
```
means:

home directory of the root user

This distinction is very important.

4. Your Website Path

Your hosting structure has looked like:
```
/storage/websites/
```
Inside:
```
/storage/websites/
├── domain1.com/
├── domain2.com/
└── domain3.com/
```
Each domain can have its own directory.

5. Example

Suppose:
```
/storage/websites/templates.cresignsys.com/public/
```
contains:
```
public/
├── index.php
├── wp-admin/
├── wp-content/
├── wp-includes/
└── wp-config.php
```
This is your WordPress document root.

6. Path

A path identifies where something exists.

For example:
```
/storage/websites/templates.cresignsys.com/public/index.php
```
Break it down:
```
/
└── storage
    └── websites
        └── templates.cresignsys.com
            └── public
                └── index.php
```
7. Absolute Path

A path beginning with:
```
/
```
is an absolute path.

Example:
```
/storage/websites/templates.cresignsys.com/public
```
It starts from filesystem root.

8. Relative Path

A relative path depends on your current directory.

If you are inside:
```
/storage/websites/templates.cresignsys.com/
```
then:
```
public/index.php
```
refers to:
```
/storage/websites/templates.cresignsys.com/public/index.php
```
9. pwd

To find your current directory:
```
pwd
```
Example:
```
/storage/websites/templates.cresignsys.com/public
```
pwd means:

Print Working Directory

10. ls

To see files:
```
ls
```
More detailed:
```
ls -l
```
Including hidden files:
```
ls -la
```
11. Example ls -l

You may see:
```
-rw-r--r-- 1 www-data www-data 1234 Aug 13 index.php
```
This line contains a lot of information.

Let’s decode it.

12. First Character
```
-rw-r--r--
^
```
The first character tells you the object type.

Common examples:
```
-
```
regular file.
```
d
```
directory.
```
l
```
symbolic link.

So:
```
-rw-r--r--
```
is a regular file.

13. Permission Characters

After the first character:
```
rw-r--r--
```
There are three groups:
```
rw-
r--
r--
```
These correspond to:
```
Owner
Group
Others
```
14. Read
```
r
```
means:

Read

For a file, read means the process can read its contents.

For a directory, read has a different meaning: it allows listing directory entries, subject to other permissions.

15. Write
```
w
```
means:

Write

For a file:
```
w
```
allows modifying its contents.

For a directory, write is related to creating, deleting, and renaming entries within it.

16. Execute
```
x
```
means:

Execute

For an ordinary executable file, it allows execution.

For a directory, x means the process can traverse/access entries within that directory, subject to other permissions.

This distinction is extremely important for web hosting.

17. Three Permission Groups

Consider:
```
rw-r--r--
```
Break it:
```
rw- | r-- | r--
 │     │     │
 │     │     └── Others
 │     └──────── Group
 └────────────── Owner
```
18. Example
```
-rw-r--r--
```
means:
```
Owner:
rw-

Group:
r--

Others:
r--
```
So:
```
Owner → read + write
Group → read
Others → read
```
19. Numeric Permissions

Linux also represents permissions numerically.

The values are:
```
r = 4
w = 2
x = 1
```
Add them.

20. 7
```
rwx
```
means:
```
4 + 2 + 1 = 7
```
21. 6
```
rw-
```
means:
```
4 + 2 = 6
```
22. 5
```
r-x
```
means:
```
4 + 1 = 5
```
23. 4
```
r--
```
means:
```
4
```
24. 0
```
---
```
means:
```
0
```
25. 755

A very common directory permission:
```
755
```
means:
```
Owner:
7 = rwx

Group:
5 = r-x

Others:
5 = r-x
```
So:
```
rwxr-xr-x
```
26. 644

A common file permission:
```
644
```
means:
```
Owner:
6 = rw-

Group:
4 = r--

Others:
4 = r--
```
Therefore:
```
rw-r--r--
```
27. Why 644 Is Common for Files

A normal web file such as:
```
index.php
style.css
logo.png
```
usually needs to be readable by the web server.

It doesn’t normally need to be executable as a Unix program.

Therefore:
```
644
```
is often appropriate.

But permissions must always be determined from the actual application and deployment model.

28. Why 755 Is Common for Directories

A directory generally needs:
```
r
```
to list entries and:
```
x
```
to traverse it.

A common configuration is:
```
755
```
allowing the owner full access and others read/traverse access.

Again, the correct permissions depend on the application.

29. Owner

Now consider:
```
-rw-r--r-- 1 www-data www-data index.php
```
The first:
```
www-data
```
is the owner.

The second:
```
www-data
```
is the group.

30. User

Linux identifies users.

Examples:
```
root
ubuntu
www-data
```
Each has a user ID.

The kernel uses these identities when enforcing permissions.

31. Group

A user can belong to one or more groups.

Groups allow permissions to be shared among multiple users/processes.

For example:
```
webadmins
```
could contain administrators who need access to website files.

32. Root

root is the superuser.

Conceptually:
```
root
 ↓
very high system privileges
```
Root can bypass many ordinary filesystem permission restrictions.

That power must be used carefully.

33. sudo

If you are logged in as:
```
ubuntu
```
you may use:
```
sudo command
```
to execute a command with elevated privileges if your account is authorized.

For example:
```
sudo systemctl reload nginx
```
34. Why sudo Matters

Changing:
```
/etc/nginx/
```
usually requires elevated privileges.

But editing your website’s own files may not require root.

A good principle is:

Use the minimum privileges required for the task.

35. www-data

On Debian/Ubuntu web servers, services such as Nginx and PHP-FPM commonly use:
```
www-data
```
as their service user, though the exact configuration should be checked.

36. Why www-data Matters

Suppose:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
```
and PHP-FPM runs as:
```
www-data
```
Then PHP processes access files as that Linux user.

Therefore:
```
PHP-FPM
 ↓
Linux permissions
 ↓
website files
```
37. WordPress Needs Write Access

WordPress may need to write files for things such as:
```
uploads
plugin installation
theme installation
updates
generated cache files
temporary files
```
Whether WordPress should have write access to all of the site is a security/design decision.

Giving the entire WordPress tree broad write access is generally undesirable.

38. Security Principle

Don’t simply do:
```
chmod -R 777 /storage/websites/example.com
```
This is a major mistake.

777 means:
```
Owner  = rwx
Group  = rwx
Others = rwx
```
Everyone gets broad read/write/execute access.

39. Why 777 Is Dangerous

Imagine an attacker finds a vulnerability in a website.

If everything is writable:
```
Attacker
 ↓
Web application vulnerability
 ↓
Write anywhere
 ↓
Upload/modify files
 ↓
Persistence
```
The impact can become much worse.

40. Principle of Least Privilege

A fundamental security principle:

Give a process only the permissions it actually needs.

For example:
```
Static assets
 ↓
read-only for web server
```
while:
```
wp-content/uploads
 ↓
write access where needed
```
This creates a smaller attack surface.

41. Directory Permissions Are Different

Suppose:
```
drwxr-xr-x
```
The x on a directory means:

Can traverse this directory.

Without directory execute permission, even if a user can read the directory listing, access to files inside can still fail.

42. Example

Imagine:
```
/storage
   ↓
/websites
   ↓
/example.com
   ↓
/public
```
The web-service user needs appropriate traversal permissions through every parent directory.

If one parent directory blocks traversal:
```
/storage
   ↓
permission denied
```
Nginx may fail to serve the website.

43. chmod

chmod changes permissions.

Example:
```
chmod 644 index.php
```
or:
```
chmod 755 public
```
44. Symbolic Permissions

Instead of:
```
chmod 644 file
```
you can use:
```
chmod u=rw,g=r,o=r file
```
This means:
```
u = user/owner
g = group
o = others
```
45. chown

chown changes ownership.

Example:
```
sudo chown www-data:www-data index.php
```
This sets:
```
owner = www-data
group = www-data
```
46. chgrp

chgrp changes the group without changing the owner.

Example:
```
sudo chgrp webadmins file.txt
```
47. Ownership vs Permissions

Don’t confuse these.

Ownership answers:
```
Who owns this?
```
Permissions answer:
```
What can the owner/group/others do?
```
48. Example

Suppose:
```
-rw-r----- 
root webadmins
```
Then:
```
Owner:
root → read/write

Group:
webadmins → read

Others:
no access
```
49. id

To see your current user and groups:
```
id
```
Example:
```
uid=1000(ubuntu) gid=1000(ubuntu) groups=...
```
50. Check www-data

You can inspect:
```
id www-data
```
This tells you the user ID and group memberships.

51. Find Nginx User

Inspect Nginx configuration:
```
grep -n "user " /etc/nginx/nginx.conf
```
You may see something like:
```
user www-data;
```
52. Find PHP-FPM User

The PHP-FPM pool configuration determines the worker user.

Depending on PHP version, inspect:
```
grep -R "^[[:space:]]*user[[:space:]]*=" /etc/php/*/fpm/pool.d/
```
and:
```
grep -R "^[[:space:]]*group[[:space:]]*=" /etc/php/*/fpm/pool.d/
```
You may see:
```
user = www-data
group = www-data
```
53. Nginx and PHP-FPM May Both Use www-data

A common architecture is:
```
Nginx
 ↓
www-data

PHP-FPM
 ↓
www-data
```
This simplifies access to website files.

But it also means you should carefully design write permissions.

54. Website Directory Design

A clean hosting structure could be:
```
/storage/websites/
│
├── example.com/
│   ├── public/
│   ├── logs/
│   └── private/
│
├── shop.example.com/
│   ├── public/
│   ├── logs/
│   └── private/
│
└── learn.example.com/
    ├── public/
    ├── logs/
    └── private/
```
The key principle is:
```
public/
=
web-accessible area
```
55. Public vs Private

Suppose:
```
/storage/websites/example.com/public/
```
is Nginx’s document root.

Anything inside this directory may potentially be served through HTTP if the Nginx configuration permits it.

Therefore don’t put secrets there.

56. Dangerous Files

Never intentionally expose things such as:
```
.env
private keys
database backups
SSH keys
application secrets
configuration credentials
```
through the public document root.

57. WordPress wp-config.php

WordPress has:
```
wp-config.php
```
which may contain database credentials and security secrets.

Therefore:
```
public/wp-config.php
```
must be protected by the web-server/application architecture.

Modern WordPress/Nginx setups generally prevent direct source disclosure of PHP files because PHP is executed rather than served as plain text, but defense-in-depth still matters.

58. PHP Source Must Not Be Downloadable

If a PHP file were accidentally served as:
```
text/plain
```
instead of being processed by PHP-FPM, its source code could be exposed.

Correct architecture:
```
.php
 ↓
Nginx
 ↓
PHP-FPM
 ↓
execute
```
not:
```
.php
 ↓
Browser downloads source
```
59. Permissions and WordPress

A typical security-oriented approach is:
```
WordPress core
 ↓
mostly read-only

Uploads/cache areas
 ↓
writeable as required
```
The exact strategy depends on how you administer WordPress.

60. Linux File Permissions Are Not the Only Layer

A file can be restricted by:
```
Unix permissions
+
ACLs
+
SELinux/AppArmor
+
Nginx rules
+
PHP-FPM restrictions
+
filesystem mount options
```
Ubuntu commonly uses AppArmor for some services.

61. ACL

ACL means:

Access Control List

ACLs can provide permissions beyond the simple:
```
owner
group
others
```
model.

For example:
```
user A → read/write
user B → read
group C → read
```
on the same file.

62. getfacl

To inspect ACLs:
```
getfacl file.txt
```
If your server doesn’t use custom ACLs, the output may closely resemble normal permissions.

63. setfacl

ACLs can be changed with:
```
setfacl
```
But don’t introduce ACL complexity unless you actually need it.

For a hosting platform, simple ownership/groups are often easier to maintain.

64. Symbolic Links

You may see:
```
lrwxrwxrwx
```
The first character:
```
l
```
means:

Symbolic link

A symbolic link points to another path.

65. Let’s Encrypt Uses Links

This is particularly relevant to your server.

Certbot commonly maintains:
```
/etc/letsencrypt/live/domain/
```
with symbolic links to files under:
```
/etc/letsencrypt/archive/domain/
```
Conceptually:
```
live/
 ↓
symbolic link
 ↓
archive/
```
This is one reason you should not casually delete or replace those files manually.

66. Inspect the Links

Run:
```
sudo ls -la /etc/letsencrypt/live/templates.cresignsys.com/
```
You may see entries similar to:
```
cert.pem -> ../../archive/.../cert1.pem
chain.pem -> ../../archive/.../chain1.pem
fullchain.pem -> ../../archive/.../fullchain1.pem
privkey.pem -> ../../archive/.../privkey1.pem
```
The exact numbering can vary.

67. Why live/ Exists

Certbot can maintain stable paths:
```
/etc/letsencrypt/live/domain/fullchain.pem
```
while the actual versioned certificate files live elsewhere.

Nginx can keep referencing the stable path.

When renewal occurs, the links can be updated to the latest version.

68. Certificate Renewal Connection

Now connect the filesystem lesson to TLS:
```
Certbot
 ↓
new certificate
 ↓
/etc/letsencrypt/archive/
 ↓
updates /live/ links
 ↓
Nginx reload
 ↓
new certificate used
```
This is why file permissions and symlinks matter to SSL automation.

69. ls -l Is a Core Skill

You should become comfortable reading:
```
ls -la
```
because it tells you:
```
file type
permissions
owner
group
size
timestamp
name
symlink target
```
70. stat

For deeper information:
```
stat index.php
```
You can see:
```
File
Size
Blocks
IO Block
Device
Inode
Links
Access
Uid
Gid
Access time
Modify time
Change time
```
71. Inode

Every filesystem object has an:

inode

The inode stores metadata associated with a filesystem object.

Conceptually:
```
Filename
   ↓
directory entry
   ↓
inode
   ↓
metadata + file data references
```
72. Filename vs Inode

A filename isn’t the file’s entire identity internally.

The filesystem maintains a relationship:
```
directory
   ↓
name → inode
```
This explains concepts such as hard links.

73. Hard Link

A hard link is another directory entry referring to the same inode.

Conceptually:
```
file1
  │
  ▼
inode 123

file2
  │
  ▼
inode 123
```
Both names refer to the same underlying inode.

74. Symbolic Link

A symbolic link is different:
```
link
 ↓
path to another object
```
It doesn’t point directly to the target inode in the same way a hard link does.

75. Why This Matters to Hosting

You will encounter symbolic links in:
```
Let's Encrypt
PHP configurations
Nginx configurations
Application deployments
Release management
```
Understanding them prevents many mistakes.

76. Disk Space

Website files ultimately consume storage.

Check:
```
df -h
```
This shows filesystem capacity.

Example:
```
Filesystem
Size
Used
Avail
Use%
Mounted on
```
77. Directory Size

To inspect a website:
```
du -sh /storage/websites/templates.cresignsys.com
```
For more detail:
```
du -sh /storage/websites/templates.cresignsys.com/*
```
This helps identify what is consuming disk space.

78. Disk vs Inode Exhaustion

A server can have free disk space but still run out of inodes.

Check:
```
df -i
```
This is particularly relevant to hosting servers with huge numbers of small files.

79. Why Hosting Servers Can Have Many Files

WordPress can contain:
```
Core files
Plugins
Themes
Uploads
Cache
Logs
Temporary files
```
A server hosting hundreds of sites can therefore contain millions of filesystem objects.

80. Permissions + Storage + Nginx

A web request ultimately becomes:
```
HTTP
 ↓
Nginx
 ↓
Filesystem
 ↓
Linux kernel
 ↓
Permission check
 ↓
Disk
```
The kernel decides whether the Nginx/PHP process is allowed to perform the operation.

81. Linux Kernel Is the Authority

This is a deep concept.

Nginx does not decide:

www-data is allowed to read this file.

The Linux kernel enforces filesystem access.

Conceptually:
```
Nginx process
 ↓
system call
 ↓
Linux kernel
 ↓
permission check
 ↓
filesystem
```
82. System Call

Programs interact with the kernel through system calls.

For example, a program may request:
```
open file
read file
write file
```
The kernel decides whether the operation is permitted.

83. Example

Nginx wants:
```
read:
/storage/websites/example.com/public/index.html
```
Conceptually:
```
Nginx
 ↓
open()
 ↓
Linux kernel
 ↓
check permissions
 ↓
allow/deny
```
If denied:
```
Permission denied
```
84. This Explains 403

Suppose Nginx receives:
```
GET /secret.html
```
but cannot read the file.

The result may become:
```
403 Forbidden
```
depending on the configuration and exact reason.

85. This Explains PHP Errors Too

Suppose PHP-FPM tries to write:
```
wp-content/uploads/
```
but doesn’t have permission.

Then:
```
WordPress
 ↓
PHP-FPM
 ↓
Linux permission check
 ↓
DENIED
```
WordPress may report an upload or filesystem error.

86. Three Different Users

On your server you might have:
```
ubuntu
root
www-data
```
They serve different purposes.

ubuntu

Administrative login user.

root

System superuser.

www-data

Web-service/application user.

The exact users on your system should be verified.

87. Why Don’t Run Everything as Root?

If PHP-FPM ran as root:
```
PHP vulnerability
 ↓
attacker
 ↓
root privileges
 ↓
potential full server compromise
```
Running services with restricted privileges limits the potential impact.

88. Security Model

A strong hosting architecture tries to separate:
```
Administrator
     ↓
root/sudo

Web server
     ↓
limited service user

Database
     ↓
database-specific account

Website
     ↓
restricted filesystem permissions
```
89. Database User Is Separate

WordPress doesn’t normally connect to MySQL as Linux root.

It uses database credentials stored in its configuration.

Conceptually:
```
WordPress
 ↓
MySQL credentials
 ↓
MySQL user
 ↓
specific database
```
This is another layer of least privilege.

90. Linux User vs MySQL User

Don’t confuse:
```
Linux:
www-data
```
with:
```
MySQL:
wordpress_user
```
They belong to different security systems.

91. Complete Security Boundary

Your website now has several independent layers:
```
Internet
 ↓
Cloud firewall
 ↓
Ubuntu networking
 ↓
Nginx
 ↓
TLS
 ↓
Linux user
 ↓
Filesystem permissions
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL user
 ↓
Database permissions
```
92. Practical Inspection

For your website, start with:
```
ls -ld /storage
ls -ld /storage/websites
ls -ld /storage/websites/templates.cresignsys.com
ls -ld /storage/websites/templates.cresignsys.com/public
```
This shows directory permissions and ownership at every level.

93. Inspect WordPress Files
```
ls -la /storage/websites/templates.cresignsys.com/public
```
Look for:
```
index.php
wp-config.php
wp-admin/
wp-content/
wp-includes/
```
94. Inspect Ownership
```
sudo stat /storage/websites/templates.cresignsys.com/public/index.php
```
Look for:
```
Uid
Gid
Access
```
95. Test Access as www-data

A very useful diagnostic:
```
sudo -u www-data ls \
/storage/websites/templates.cresignsys.com/public
```
This asks:

Can the www-data user actually list this directory?

96. Test Reading a File
```
sudo -u www-data cat \
/storage/websites/templates.cresignsys.com/public/index.php
```
If permission is denied, you have identified a filesystem-access problem.

Be careful with commands that print sensitive configuration files such as wp-config.php.

97. Test Directory Traversal

You can inspect each parent:
```
namei -l /storage/websites/templates.cresignsys.com/public/index.php
```
This is an excellent command.

It shows permissions/ownership along the entire path.

98. Why namei Is Powerful

Suppose:
```
/storage
```
is inaccessible to www-data.

Even if:
```
public/index.php
```
has:
```
644
```
Nginx may still fail.

namei -l helps find the exact blocking directory.

99. The Practical Permission Model

A useful starting principle for a typical WordPress hosting setup is:
```
Directories
≈ 755

Files
≈ 644
```
but don’t blindly apply these recursively to every file.

Sensitive files and writable directories may need different permissions.

100. Never Blindly Run Recursive Permission Commands

Avoid blindly doing:
```
chmod -R 777 ...
```
or:
```
chown -R www-data:www-data /
```
The second could be catastrophic.

Always specify the exact website directory and understand what you’re changing.

101. Your Hosting Platform

For your CresignSys Hosting Platform, a better model is:
```
/storage/websites/
│
├── site1/
│   ├── public/
│   ├── logs/
│   └── private/
│
├── site2/
│   ├── public/
│   ├── logs/
│   └── private/
│
└── site3/
    ├── public/
    ├── logs/
    └── private/
```
Then your automation can consistently create:
```
directory
ownership
permissions
Nginx configuration
PHP-FPM configuration
SSL configuration
logs
```
102. Hosting Automation Flow

Eventually your hosting-create script can do:
```
Create domain
     ↓
Create directories
     ↓
Set ownership
     ↓
Set permissions
     ↓
Create Nginx config
     ↓
Test Nginx
     ↓
Reload Nginx
     ↓
Create DNS record
     ↓
Issue Let's Encrypt certificate
     ↓
Install certificate
     ↓
Configure HTTPS
     ↓
Install WordPress
```
You are now learning the individual layers behind that automation.

103. Deep Architecture

We can now expand the stack:
```
                    INTERNET
                       │
                       ▼
                      DNS
                       │
                       ▼
                    ROUTING
                       │
                       ▼
                    TCP/UDP
                       │
                       ▼
                      TLS
                       │
                       ▼
                      HTTP
                       │
                       ▼
                     NGINX
                       │
                ┌──────┴──────┐
                ▼             ▼
           FILESYSTEM      PHP-FPM
                              │
                              ▼
                          WORDPRESS
                              │
                              ▼
                            MYSQL
                              │
                              ▼
                          STORAGE
```
And underneath everything:
```
Linux Kernel
     ↓
CPU
     ↓
RAM
     ↓
Disk/Storage
     ↓
Network Interface
```
104. The Next Level

We have now reached an important boundary.

We understand:
```
DNS
IP
TCP
TLS
HTTP
Nginx
Filesystem
Permissions
```
The next major component is:

PHP-FPM

because this is the bridge between:
```
Nginx
```
and:
```
WordPress
```
Lesson 043 Summary

The most important concepts are:
```
Path
=
location of a filesystem object

Owner
=
user associated with the object

Group
=
group associated with the object

Permissions
=
read/write/execute rules

www-data
=
common web-service user

root
=
superuser

chmod
=
change permissions

chown
=
change ownership

sudo
=
execute with elevated privileges

inode
=
filesystem metadata/object identifier

symlink
=
link pointing to another path
```
For your hosting server:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
Linux kernel
 ↓
Filesystem
```
Linux permissions determine whether those processes can actually access the files they need.

Next Lesson — 044

PHP-FPM From Zero — How PHP Actually Runs on Your Server

We will trace:
```
Browser
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP worker process
 ↓
WordPress
 ↓
MySQL
```
and go deeply into:
```
PHP
PHP-FPM
FPM pools
workers
Unix sockets
FastCGI
php.ini
memory limits
execution limits
OPcache
PHP versions
PHP 8.x
process management
www-data
security isolation
```
This is the next major foundation for understanding why WordPress hosting works.
August 13, 2026
CresignSys Learn — Lesson 042
Nginx From Zero: How a Web Server Actually Processes a Request

We now move from HTTP theory into the actual technology running your websites.

Your architecture is approximately:
```
Browser
   ↓
DNS
   ↓
Internet
   ↓
Ubuntu VPS
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
```
Today we focus almost entirely on:

Nginx

1. What Is Nginx?

Nginx is a high-performance web server and reverse proxy.

It can perform several jobs:
```
Nginx
│
├── Web server
├── TLS endpoint
├── Reverse proxy
├── HTTP router
├── Static-file server
├── Load balancer
└── Access-control layer
```
For your hosting platform, the most important roles initially are:
```
HTTP server
+
TLS termination
+
Static file server
+
PHP-FPM gateway
```
2. Nginx Is Not PHP

This distinction is fundamental.
```
Nginx
=
web server
```
while:
```
PHP-FPM
=
PHP application execution manager
```
and:
```
WordPress
=
PHP application
```
So:
```
Browser
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
```
3. Nginx Does Not Normally Execute PHP

Suppose the browser requests:
```
/wp-login.php
```
Nginx doesn’t normally interpret PHP itself.

Instead:
```
Browser
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP interpreter
```
4. Nginx Can Serve Static Files Directly

Suppose the browser requests:
```
/logo.png
```
Nginx can do:
```
Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
logo.png
 ↓
Browser
```
No PHP needed.

5. Why This Is Efficient

Imagine your website contains:
```
logo.png
style.css
script.js
font.woff2
```
These are static resources.

There is no reason to start WordPress for every one of them.

Nginx can serve them directly.

6. Nginx Configuration

Nginx is controlled through configuration files.

A common main configuration is:
```
/etc/nginx/nginx.conf
```
Additional configurations may be included from directories such as:
```
/etc/nginx/conf.d/
```
and on Debian/Ubuntu systems commonly:
```
/etc/nginx/sites-available/
/etc/nginx/sites-enabled/
```
Your exact installation may use a custom structure.

7. Configuration Is Text

Nginx configuration is declarative.

Example:
```
server {
    listen 80;
    server_name example.com;

    root /var/www/example;
}
```
This tells Nginx how to handle requests.

8. server {}

The fundamental Nginx virtual-host structure is:
```
server {
    ...
}
```
A server block defines a virtual server.

Think:
```
server {}
=
one website/server configuration
```
9. Multiple Websites

You can have:
```
server {
    server_name site1.com;
}

server {
    server_name site2.com;
}

server {
    server_name site3.com;
}
```
All can potentially run on the same machine/IP.

This is the foundation of multi-domain hosting.

10. listen

Example:
```
listen 80;
```
means Nginx listens for HTTP traffic on port 80.

For HTTPS:
```
listen 443 ssl;
```
means the server handles TLS/HTTPS traffic on port 443.

Modern Nginx configurations can express TLS settings in different ways depending on version and configuration style.

11. Port 80 vs 443

Remember:
```
80
 ↓
HTTP

443
 ↓
HTTPS/TLS
```
A common architecture is:
```
HTTP :80
    ↓
301/308 redirect
    ↓
HTTPS :443
```
12. server_name

Example:
```
server_name templates.cresignsys.com;
```
This associates the server block with the hostname.

So:
```
templates.cresignsys.com
        ↓
Nginx
        ↓
matching server block
```
13. root

Example:
```
root /storage/websites/templates.cresignsys.com/public;
```
This tells Nginx the filesystem root for static resources in that server context.

So:
```
/logo.png
```
can correspond conceptually to:
```
/storage/websites/templates.cresignsys.com/public/logo.png
```
14. Important: URL ≠ Filesystem

A request:
```
/about/
```
doesn’t necessarily mean:
```
/storage/.../about/
```
The mapping depends on Nginx configuration and potentially application routing.

This becomes very important with WordPress.

15. location

Nginx uses:
```
location / {
    ...
}
```
to determine how a URI should be processed.

Think:
```
URL path
   ↓
location matching
   ↓
processing rules
```
16. Basic Location

Example:
```
location / {
    try_files $uri $uri/ /index.php?$args;
}
```
This is a common WordPress pattern.

It means approximately:
```
Try requested file
        ↓
If not found, try directory
        ↓
Otherwise send request to WordPress
```
17. try_files

This directive is extremely important for WordPress.

Example:
```
try_files $uri $uri/ /index.php?$args;
```
Conceptually:
```
Request /about/

        ↓

Does file exist?
        ↓
      NO

Does directory exist?
        ↓
      maybe

Otherwise:
        ↓
/index.php
```
18. Why WordPress Needs This

WordPress uses:

Pretty URLs

For example:
```
/about/
/contact/
/services/website-hosting/
```
There may be no physical file:
```
/about/index.html
```
Instead WordPress handles the route.

19. WordPress Front Controller

WordPress commonly uses:
```
index.php
```
as a central entry point.

Conceptually:
```
Request
 ↓
Nginx
 ↓
index.php
 ↓
WordPress
 ↓
Routing
 ↓
Page
```
This architecture is often called a:

Front controller

20. Example

Browser requests:
```
/about/
```
Nginx:
```
Does /about/ exist?
```
Suppose no physical file exists.

Then:
```
/index.php
```
is used.

WordPress receives:
```
/about/
```
through the request environment and determines what content to generate.

21. PHP Location

A typical Nginx configuration contains something conceptually like:
```
location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
```
The exact PHP version/socket on your server must be checked.

22. What Does ~ \.php$ Mean?

This is a regular-expression location.

It roughly matches URI paths ending in:
```
.php
```
For example:
```
/index.php
/wp-login.php
/wp-cron.php
```
23. FastCGI

Nginx communicates with PHP-FPM using:

FastCGI

Conceptually:
```
Nginx
  │
  │ FastCGI
  ▼
PHP-FPM
```
FastCGI is a protocol/interface for passing requests to application processes.

24. PHP-FPM Socket

On Ubuntu, PHP-FPM may listen through a Unix socket such as:
```
/run/php/php8.1-fpm.sock
```
or another version:
```
/run/php/php8.3-fpm.sock
```
The exact path depends on your installed PHP version/configuration.

25. Unix Socket

A Unix socket is a local IPC mechanism.

IPC means:

Inter-Process Communication

Instead of:
```
Nginx
 ↓
Internet
 ↓
PHP-FPM
```
both processes communicate locally:
```
Nginx
 │
 │ Unix socket
 ▼
PHP-FPM
```
26. Why Use a Unix Socket?

For services on the same server, a Unix socket can provide an efficient local communication mechanism.

Another possibility is TCP:
```
127.0.0.1:9000
```
Both approaches are common.

27. fastcgi_pass

Example:
```
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
```
means:

Send the FastCGI request to this PHP-FPM endpoint.

28. SCRIPT_FILENAME

One particularly important parameter is:
```
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
```
It tells PHP-FPM which actual filesystem script should be executed.

For example:
```
Document root:
/storage/websites/templates.cresignsys.com/public

Script:
index.php
```
becomes approximately:
```
/storage/websites/templates.cresignsys.com/public/index.php
```
29. The Complete PHP Request

For:
```
/wp-login.php
```
the flow becomes:
```
Browser
 ↓
HTTPS
 ↓
Nginx
 ↓
location ~ \.php$
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
/storage/websites/.../wp-login.php
 ↓
WordPress
```
30. What Happens With CSS?

Request:
```
/wp-content/themes/.../style.css
```
Nginx can usually serve it directly:
```
Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
style.css
```
PHP-FPM isn’t needed.

31. What Happens With wp-login.php?

Request:
```
/wp-login.php
```
typically:
```
Browser
 ↓
Nginx
 ↓
PHP location
 ↓
PHP-FPM
 ↓
wp-login.php
 ↓
WordPress
```
32. What Happens With /about/?

Usually:
```
Browser
 ↓
Nginx
 ↓
location /
 ↓
try_files
 ↓
not a physical file
 ↓
/index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
route /about/
```
33. The Nginx Decision Tree

Think of Nginx approximately like:
```
Request arrives
      │
      ▼
Which server_name?
      │
      ▼
Which location?
      │
      ├── Static resource?
      │       ↓
      │    Filesystem
      │
      └── PHP?
              ↓
           FastCGI
              ↓
          PHP-FPM
```
The actual Nginx location-selection algorithm is more nuanced than this simplified tree.

34. TLS Comes Before HTTP Processing

For HTTPS:
```
TCP connection
 ↓
TLS handshake
 ↓
Encrypted HTTP
 ↓
Nginx HTTP processing
```
So the layers are:
```
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx routing
```
35. SNI and server_name

This is a particularly useful connection.

During TLS:
```
SNI:
templates.cresignsys.com
```
Then HTTP contains:
```
Host: templates.cresignsys.com
```
Nginx uses the available information to select the appropriate virtual server configuration.

36. Multiple Domains

Imagine:
```
IP: 203.0.113.10

             Nginx
               │
      ┌────────┼────────┐
      ▼        ▼        ▼
   site A    site B   site C
```
Each can have:
```
server_name
root
TLS certificate
logs
PHP configuration
```
37. Hosting Platform

This is exactly why your hosting platform can create websites automatically.

Your script can generate:
```
server {
    listen 443 ssl;
    server_name example.com;

    root /storage/websites/example.com/public;

    ...
}
```
Then:
```
nginx -t
```
and:
```
systemctl reload nginx
```
The new website becomes active.

38. Configuration Test

Never blindly reload after editing Nginx.

First:
```
sudo nginx -t
```
You want something equivalent to:
```
syntax is ok
test is successful
```
39. Then Reload

If the configuration test succeeds:
```
sudo systemctl reload nginx
```
This tells Nginx to reload configuration without requiring a full service restart.

40. Check Nginx Status
```
sudo systemctl status nginx
```
Useful for seeing:
```
running
failed
inactive
```
41. Check Configuration

A powerful command:
```
sudo nginx -T
```
This prints the complete effective Nginx configuration after includes are processed.

This is extremely useful when debugging complex hosting systems.

42. Find Website Configuration

You can search:
```
sudo nginx -T | grep -n "templates.cresignsys.com"
```
This helps locate where Nginx sees the domain configuration.

43. Logs

Nginx commonly has:
```
/var/log/nginx/
```
with logs such as:
```
access.log
error.log
```
Your configuration may also use separate per-site logs.

44. Access Log

The access log records requests.

Conceptually:
```
GET /about/ HTTP/2
200
```
It can help answer:

What requests are actually reaching the server?

45. Error Log

The error log helps investigate problems such as:
```
PHP-FPM connection failure
Permission denied
File not found
Configuration errors
Upstream failures
```
46. Example Diagnostic

Suppose the browser says:
```
502 Bad Gateway
```
Check:
```
sudo tail -f /var/log/nginx/error.log
```
Then make the request again.

You might discover:
```
connect() to unix:/run/php/php8.x-fpm.sock failed
```
That immediately points toward PHP-FPM/socket configuration.

47. Another Example

Suppose:
```
403 Forbidden
```
Possible areas:
```
Filesystem permissions
Nginx configuration
Directory access
Security rules
Application behavior
```
The error log helps narrow it down.

48. Filesystem Permissions

Suppose your root is:
```
/storage/websites/templates.cresignsys.com/public
```
Nginx needs sufficient permission to read files.

PHP-FPM also needs appropriate access to execute/read the necessary files.

This creates an important relationship:
```
Nginx
+
PHP-FPM
+
Linux permissions
```
49. Linux Users

Your services may run under accounts such as:
```
www-data
```
This is common on Debian/Ubuntu web servers.

The exact user depends on your configuration.

50. Why Ownership Matters

Suppose:
```
file owner = root
permissions = 600
```
and Nginx/PHP-FPM runs as:
```
www-data
```
The web service may not be able to access the file.

This can cause:
```
403
500
application failures
```
depending on the situation.

51. Nginx and WordPress Architecture

Your WordPress website therefore becomes:
```
                  INTERNET
                     │
                     ▼
                 TCP :443
                     │
                     ▼
                    TLS
                     │
                     ▼
                   NGINX
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
      Static files           PHP-FPM
                                  │
                                  ▼
                              WordPress
                                  │
                                  ▼
                                MySQL
```
52. Nginx Is the Traffic Controller

A useful mental model:

Nginx is the traffic controller at the front door of your website.

It decides:
```
Which domain?
Which port?
Which URL?
Which file?
Which application?
Which upstream?
Which response?
```
53. Reverse Proxy

Nginx can also forward requests to another application.

For example:
```
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}
```
Then:
```
Browser
 ↓
Nginx
 ↓
Node.js :3000
```
The browser doesn’t need to know that the application runs on port 3000.

54. PHP vs Reverse Proxy

PHP commonly uses:
```
FastCGI
```
Other applications might use:
```
HTTP reverse proxy
```
For example:
```
Nginx
 ↓
Node.js
```
or:
```
Nginx
 ↓
Python/Gunicorn
```
55. Nginx Can Host Many Technologies

For example:
```
Nginx
│
├── HTML
├── PHP
├── WordPress
├── Node.js
├── Python
├── Go
├── Java applications
└── Reverse-proxied services
```
Nginx itself isn’t the application.

It is often the front-facing web layer.

56. The Most Important Nginx Concepts

Memorize:
```
server
=
virtual server

listen
=
network port/address

server_name
=
hostname matching

root
=
filesystem root

location
=
URI routing rules

try_files
=
filesystem/application fallback

fastcgi_pass
=
send request to PHP-FPM

proxy_pass
=
reverse proxy to HTTP upstream

access_log
=
request log

error_log
=
error/debug log
```
57. Typical WordPress Configuration

A simplified example:
```
server {
    listen 80;
    server_name templates.cresignsys.com;

    root /storage/websites/templates.cresignsys.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
```
This is an educational example; your production configuration should match the PHP version, security requirements, and existing hosting setup.

58. HTTPS Version

A simplified HTTPS server might look conceptually like:
```
server {
    listen 443 ssl;
    server_name templates.cresignsys.com;

    root /storage/websites/templates.cresignsys.com/public;

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

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

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
```
Again, the PHP socket and exact directives must match your actual system.

59. What Happens When You Type the URL?

You type:
```
https://templates.cresignsys.com/about/
```
Step 1

Browser performs DNS resolution.
```
templates.cresignsys.com
        ↓
IP
```
Step 2

TCP connection:
```
Browser → server:443
```
Step 3

TLS handshake.
```
ClientHello
ServerHello
Certificate
Key exchange
Finished
```
Step 4

HTTP request:
```
GET /about/ HTTP/2
Host: templates.cresignsys.com
```
Step 5

Nginx selects:
```
server_name
```
Step 6

Nginx evaluates:
```
location /
```
Step 7

try_files checks the requested resource.

Step 8

WordPress receives the request if no matching static resource exists.

Step 9

PHP-FPM executes the PHP code.

Step 10

WordPress queries MySQL if necessary.

Step 11

HTML comes back.

Step 12

Nginx sends the HTTP response.

Step 13

TLS protects the response.

Step 14

Browser renders the page.

60. One Complete Mental Model
```
URL
 │
 ▼
DNS
 │
 ▼
IP
 │
 ▼
TCP :443
 │
 ▼
TLS
 │
 ▼
HTTP
 │
 ▼
NGINX
 │
 ├── server_name
 │
 ├── location
 │
 ├── root
 │
 └── try_files
       │
       ├── static → filesystem
       │
       └── dynamic → FastCGI
                         │
                         ▼
                      PHP-FPM
                         │
                         ▼
                      WordPress
                         │
                         ▼
                       MySQL
```
This is the architecture you need to understand before building a serious multi-domain hosting platform.

Lesson 042 Summary

The key idea:

Nginx receives the HTTP request and decides what should happen to it.

For a static file:
```
Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
Response
```
For WordPress:
```
Browser
 ↓
Nginx
 ↓
try_files
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTML
 ↓
Nginx
 ↓
Browser
```
For HTTPS:
```
Browser
 ↓
TCP :443
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
```
Next Lesson — 043

Linux Filesystem + Permissions — The Hidden Foundation of Web Hosting

Before going deeper into PHP-FPM and WordPress, we need to understand why these commands matter:
```
ls -la
chown
chmod
sudo
www-data
root
```
We will go from the absolute basics:
```
File
Directory
Path
Owner
Group
Permission
Read
Write
Execute
```
to the actual hosting structure:
```
/storage/websites/
    │
    ├── domain1.com/
    │      └── public/
    │
    ├── domain2.com/
    │      └── public/
    │
    └── domain3.com/
           └── public/
```
and then understand exactly why Nginx, PHP-FPM, WordPress, Certbot, and SSH need different permissions.
August 13, 2026
CresignSys Learn — Lesson 041
HTTP — The Language of the Web

We have now studied:
```
Domain
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
```
Now we reach the protocol that actually carries the web request:

HTTP

1. What Is HTTP?

HTTP means:

Hypertext Transfer Protocol

It is an application-layer protocol used for communication between clients and web servers.

For your website:
```
Browser
   ↓
HTTPS
   ↓
HTTP
   ↓
Nginx
```
2. HTTP Is Not HTTPS

These are related but different:
```
HTTP
=
web application protocol
```
```
HTTPS
=
HTTP
+
TLS
```
So:
```
HTTPS
 │
 ├── TLS
 │    └── encryption/security
 │
 └── HTTP
      └── web requests/responses
```
3. What Does HTTP Actually Do?

HTTP defines how a client says:

Give me this resource.

and how the server says:

Here is the result.

For example:
```
GET / HTTP/1.1
Host: templates.cresignsys.com
```
The server may respond:
```
HTTP/1.1 200 OK
Content-Type: text/html
```
followed by the webpage.

4. Client and Server

HTTP normally has two primary participants:
```
Client
   ↓
Request
   ↓
Server
   ↓
Response
   ↓
Client
```
For your website:
```
Chrome
   ↓
Nginx
```
5. HTTP Request

A request tells the server what the client wants.

Example:
```
GET / HTTP/1.1
Host: templates.cresignsys.com
```
This means approximately:

Get / from templates.cresignsys.com.

6. HTTP Response

The server responds.

Example:
```
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345

<html>
...
</html>
```
7. Request Structure

A simplified HTTP request contains:
```
Request
│
├── Method
├── Target/path
├── HTTP version
├── Headers
└── Optional body
```
Example:
```
GET /about HTTP/1.1
Host: templates.cresignsys.com
User-Agent: Chrome
Accept: text/html
```
8. Method

The first word:
```
GET
```
is the HTTP method.

Common methods:
```
GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS
```
9. GET

GET means approximately:

Retrieve a representation of a resource.

Example:
```
GET /about HTTP/1.1
```
The browser is asking for:
```
/about
```
10. POST

POST is commonly used to submit data to a server.

For example:
```
POST /login HTTP/1.1
```
with a request body containing form data or JSON.

Conceptually:
```
Browser
 ↓
POST
 ↓
Server
 ↓
Process submitted data
```
11. PUT

PUT is commonly used when the client wants to create or replace a representation at a specified resource.

For APIs:
```
PUT /users/123
```
might mean:

Replace/update the representation of user 123.

12. PATCH

PATCH is generally used for partial modification.

For example:
```
PATCH /users/123
```
could change only:
```
email
```
without replacing the entire resource.

13. DELETE

DELETE requests removal of a resource.

Example:
```
DELETE /users/123
```
The server decides whether the operation is permitted and how it is handled.

14. HEAD

HEAD is similar to GET but asks for the response headers without the response body.

Useful for checking:
```
Status
Content-Type
Content-Length
Cache headers
Last-Modified
```
without downloading the complete content.

15. OPTIONS

OPTIONS asks about supported communication options for a resource/server.

It is also important in browser CORS workflows.

16. URL

Consider:
```
https://templates.cresignsys.com/about?lang=en
```
Break it down:
```
https://
   ↓
scheme

templates.cresignsys.com
   ↓
host

/about
   ↓
path

?lang=en
   ↓
query
```
17. Scheme

The scheme:
```
https
```
tells the client what protocol arrangement is being requested.

For ordinary web traffic:
```
http
https
```
18. Host

The host is:
```
templates.cresignsys.com
```
This is the hostname.

It connects our previous DNS lesson to HTTP.

19. Path

The path:
```
/about
```
identifies the requested resource within the server/application namespace.

Other examples:
```
/
 /about
 /contact
 /wp-admin/
 /wp-login.php
```
20. Query String

Example:
```
/products?id=25
```
The query is:
```
id=25
```
Another:
```
/search?q=wordpress&page=2
```
Query parameters are often used to pass request-specific information.

21. Fragment

You may see:
```
https://example.com/page#section2
```
The:
```
#section2
```
fragment is normally handled by the browser and is not sent to the server as part of the HTTP request target.

This is an important distinction.

22. HTTP Headers

Headers carry metadata.

Example:
```
Host: templates.cresignsys.com
User-Agent: Chrome
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session=...
```
Think of headers as:

Information about the request or response.

23. Host Header

In HTTP/1.1, the Host header identifies the intended host.

Example:
```
Host: templates.cresignsys.com
```
This is extremely important for shared hosting.

24. Why Host Matters

One server can host:
```
templates.cresignsys.com
shop.cresignsys.com
learn.cresignsys.com
```
The same IP can receive all three.

The HTTP host information helps Nginx select the appropriate virtual server configuration.

Conceptually:
```
IP:443
  │
  ├── templates.cresignsys.com
  ├── shop.cresignsys.com
  └── learn.cresignsys.com
```
25. SNI vs Host

These are related but different.

SNI

Used during TLS negotiation:
```
TLS
 ↓
SNI = templates.cresignsys.com
```
Host

Used by HTTP:
```
HTTP
 ↓
Host: templates.cresignsys.com
```
So:
```
TLS layer
 ↓
SNI

HTTP layer
 ↓
Host
```
26. User-Agent

The User-Agent header identifies information about the client software.

For example:
```
User-Agent: Mozilla/5.0 ...
```
Servers can use it for compatibility, analytics, or other purposes.

It should not be treated as a strong security identity.

27. Accept

The browser can tell the server what response media types it prefers.

Example:
```
Accept: text/html
```
It can contain multiple values and quality preferences.

28. Accept-Encoding

The browser may tell the server which content encodings it supports.

For example:
```
Accept-Encoding: gzip, br
```
The server may then compress the response when appropriate.

29. Content-Type

Content-Type tells the receiver what kind of representation is being sent.

Example:
```
Content-Type: text/html
```
Other examples:
```
application/json
text/css
application/javascript
image/png
image/webp
```
30. Content-Length

This indicates the size of a message body in bytes when used.

Example:
```
Content-Length: 15432
```
Modern HTTP can also use other mechanisms for delimiting message content.

31. HTTP Response

A response contains:
```
Response
│
├── Status
├── Headers
└── Body
```
Example:
```
HTTP/1.1 200 OK
Content-Type: text/html

<html>
...
</html>
```
32. Status Code

The status code tells the client what happened.

Examples:
```
200
301
302
304
400
401
403
404
500
502
503
504
```
33. 200
```
200 OK
```
Generally means the request succeeded.

34. 201
```
201 Created
```
Commonly used when a request successfully creates a resource.

Especially common in APIs.

35. 204
```
204 No Content
```
The request succeeded but there is no response content to return.

36. 301
```
301 Moved Permanently
```
The resource has been permanently redirected to another URL.

For example:
```
http://example.com
        ↓
https://example.com
```
37. 302
```
302 Found
```
A redirect response.

There are several redirect status codes, each with specific semantics.

38. 304
```
304 Not Modified
```
This is related to caching.

It can tell the browser:

You can use your existing cached copy.

This can save bandwidth.

39. 400
```
400 Bad Request
```
The server considers the request malformed or invalid.

40. 401
```
401 Unauthorized
```
Despite its name, this generally means the request lacks valid authentication credentials for the protected resource.

41. 403
```
403 Forbidden
```
The server understood the request but refuses to authorize it.

42. 404
```
404 Not Found
```
The requested resource could not be found.

For WordPress:
```
/wp-admin/
```
might work while:
```
/does-not-exist
```
returns 404.

43. 405
```
405 Method Not Allowed
```
The server/resource doesn’t support the HTTP method used for that resource.

Example:
```
DELETE /article
```
when the endpoint only allows:
```
GET
```
44. 429
```
429 Too Many Requests
```
Often used for rate limiting.

For example:
```
Client
 ↓
1000 requests
 ↓
Server
 ↓
429
```
45. 500
```
500 Internal Server Error
```
This generally means the server encountered an unexpected condition while processing the request.

In WordPress, causes can include:
```
PHP fatal error
Plugin problem
Theme problem
Configuration error
```
46. 502
```
502 Bad Gateway
```
This often occurs when a gateway/proxy such as Nginx receives an invalid response from an upstream service.

For your architecture:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
```
If Nginx cannot properly communicate with PHP-FPM, a 502 can result.

47. 503
```
503 Service Unavailable
```
Often means the service is temporarily unable to handle the request.

Possible causes include:
```
Service stopped
Overload
Maintenance
Upstream unavailable
```
48. 504
```
504 Gateway Timeout
```
A gateway/proxy waited too long for an upstream response.

For example:
```
Nginx
 ↓
PHP-FPM
 ↓
application hangs
```
Nginx may eventually return:
```
504
```
49. Status Code Families

Remember:
```
1xx
Informational

2xx
Success

3xx
Redirection

4xx
Client/request-related errors

5xx
Server-side failures
```
50. HTTP Body

The body contains the actual content.

For a webpage:
```
<html>
  <body>
    Hello
  </body>
</html>
```
For an API:
```
{
  "name": "Abey",
  "status": "active"
}
```
51. HTTP Is Not Only HTML

HTTP can transport:
```
HTML
CSS
JavaScript
JSON
Images
Fonts
PDF
Video
API data
```
HTTP is a general application protocol.

52. One Web Page Is Many HTTP Requests

When you open:
```
https://templates.cresignsys.com
```
the browser may request:
```
/
style.css
app.js
logo.png
font.woff2
api/data
```
So one page can produce many HTTP requests.

53. Example

Conceptually:
```
Browser
 │
 ├── GET /
 │
 ├── GET /style.css
 │
 ├── GET /app.js
 │
 ├── GET /logo.png
 │
 └── GET /font.woff2
```
Each resource can have its own HTTP response.

54. Browser Rendering

The browser receives:
```
HTML
```
then discovers resources:
```
CSS
JavaScript
Images
Fonts
```
and requests them.

Eventually it builds the visual page.

55. Static vs Dynamic

A file such as:
```
style.css
```
can often be served directly by Nginx.

But a WordPress page may require:
```
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
56. Static Request

Example:
```
GET /style.css
```
Nginx can potentially do:
```
Nginx
 ↓
Filesystem
 ↓
style.css
 ↓
HTTP response
```
No PHP is required.

57. Dynamic WordPress Request

Example:
```
GET /about/
```
could involve:
```
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Plugins/themes
 ↓
MySQL
 ↓
HTML generation
 ↓
PHP-FPM
 ↓
Nginx
 ↓
Browser
```
58. This Explains Web Server Performance

Static content can often be served very quickly.

Dynamic content can require:
```
PHP
Database
Plugins
Theme processing
External API calls
```
Each adds work.

59. Cookies

HTTP is fundamentally stateless.

A server does not automatically remember previous requests.

Cookies provide one common mechanism for maintaining state.

Example:
```
Cookie: session=abc123
```
60. Set-Cookie

The server can send:
```
Set-Cookie: session=abc123; Secure; HttpOnly
```
The browser stores the cookie and can send it on subsequent matching requests.

61. Cookie Flow
```
First request
     ↓
Server
     ↓
Set-Cookie
     ↓
Browser stores cookie
     ↓
Next request
     ↓
Cookie: session=...
```
62. Why WordPress Uses Cookies

WordPress uses cookies for things such as:
```
Login sessions
Authentication state
User preferences
```
So:
```
Browser
 ↓
WordPress cookie
 ↓
WordPress
 ↓
recognizes session
```
63. Secure Cookie

A cookie can have:
```
Secure
```
meaning it should only be sent over secure connections.

This is important for authentication cookies.

64. HttpOnly

A cookie can also use:
```
HttpOnly
```
which prevents ordinary JavaScript from reading the cookie through the browser’s document.cookie interface.

This can reduce exposure to certain client-side attacks, although it doesn’t make an application automatically secure.

65. SameSite

Another important cookie attribute:
```
SameSite
```
It controls when cookies are sent in cross-site contexts.

Values commonly include:
```
Strict
Lax
None
```
This is important for modern web security and CSRF defenses.

66. Sessions

A session is an application concept.

For example:
```
Browser
 ↓
session cookie
 ↓
Server
 ↓
session data
```
The cookie may contain an identifier rather than the entire session state.

67. HTTP Authentication

HTTP also has authentication mechanisms.

For example:
```
Authorization: Bearer <token>
```
or:
```
Authorization: Basic ...
```
Modern applications frequently use token-based mechanisms for APIs.

68. HTTP Is Stateless

Suppose:
```
Request 1
```
and:
```
Request 2
```
The protocol itself doesn’t automatically imply:

These are the same human.

Applications use:
```
Cookies
Sessions
Tokens
Authentication
```
to create stateful experiences.

69. HTTP Caching

HTTP has powerful caching mechanisms.

The browser may store:
```
HTML
CSS
JS
Images
API responses
```
depending on cache directives.

70. Cache-Control

A server can send:
```
Cache-Control: max-age=3600
```
This gives caching instructions.

Other directives include:
```
no-cache
no-store
private
public
must-revalidate
```
Each has specific semantics.

71. Why Caching Matters

Without caching:
```
Browser
 ↓
Server
 ↓
download logo
```
every time.

With caching:
```
Browser
 ↓
local cached logo
```
when permitted.

This reduces:
```
Bandwidth
Latency
Server load
```
72. ETag

A server can provide an:

ETag

Example:
```
ETag: "abc123"
```
The browser can later send:
```
If-None-Match: "abc123"
```
The server can respond:
```
304 Not Modified
```
if the resource hasn’t changed.

73. Last-Modified

Another caching mechanism is:
```
Last-Modified: ...
```
The client may later send:
```
If-Modified-Since: ...
```
The server can return:
```
304 Not Modified
```
when appropriate.

74. Compression

HTTP responses can be compressed.

The browser might send:
```
Accept-Encoding: gzip, br
```
The server may respond with:
```
Content-Encoding: br
```
or:
```
Content-Encoding: gzip
```
75. Compression Flow
```
HTML
 ↓
Compression
 ↓
compressed bytes
 ↓
TLS
 ↓
Internet
 ↓
Browser
 ↓
decompression
 ↓
HTML
```
This reduces transfer size.

76. HTTP/1.1

The traditional HTTP version you’ll encounter frequently is:

HTTP/1.1

Example:
```
GET / HTTP/1.1
Host: templates.cresignsys.com
```
It is text-oriented and widely supported.

77. HTTP/2

HTTP/2 introduced major performance improvements.

Conceptually:
```
One connection
      │
 ┌────┼────┬────┐
 ▼    ▼    ▼    ▼
Req1 Req2 Req3 Req4
```
It uses binary framing and supports multiplexing.

78. HTTP/2 Multiplexing

Instead of requiring a separate HTTP connection for each resource, multiple streams can share a connection.
```
TCP connection
│
├── Stream 1
├── Stream 3
├── Stream 5
└── Stream 7
```
This reduces connection overhead.

79. HTTP/3

HTTP/3 changes the transport architecture:
```
HTTP/1.1
 ↓
TCP

HTTP/2
 ↓
TCP

HTTP/3
 ↓
QUIC
 ↓
UDP
```
We will study QUIC deeply later.

80. HTTP Version Stack

Memorize:
```
HTTP/1.1
 ↓
TCP
 ↓
TLS for HTTPS

HTTP/2
 ↓
TCP
 ↓
TLS

HTTP/3
 ↓
QUIC
 ↓
UDP
```
81. Nginx’s Role

Your Nginx server is sitting between the network and your application.

Conceptually:
```
Internet
   ↓
TCP/TLS
   ↓
Nginx
   ↓
HTTP processing
   ↓
┌───────────────┐
│               │
▼               ▼
Static       PHP-FPM
files            │
                 ▼
              WordPress
                 │
                 ▼
               MySQL
```
82. Nginx Receives the Request

Suppose:
```
GET /about/ HTTP/1.1
Host: templates.cresignsys.com
```
Nginx receives it.

It needs to decide:
```
Which server?
Which location?
Static or dynamic?
Where should the request go?
```
83. server_name

Your Nginx configuration may contain:
```
server_name templates.cresignsys.com;
```
This tells Nginx that this server block handles that hostname.

84. location

Nginx then evaluates URL paths against location rules.

Example:
```
location / {
    ...
}
```
This can define how requests should be processed.

85. Static File

For a static file:
```
GET /logo.png
```
Nginx might map:
```
/logo.png
```
to:
```
/storage/websites/templates.cresignsys.com/public/logo.png
```
Then return the file.

86. PHP Request

For a PHP-backed request, Nginx may pass the request to:
```
PHP-FPM
```
using FastCGI.

Conceptually:
```
Browser
 ↓
HTTP
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP
```
87. PHP-FPM

PHP-FPM means:

PHP FastCGI Process Manager

It manages PHP worker processes.

For WordPress:
```
Nginx
 ↓
PHP-FPM
 ↓
WordPress PHP
```
88. WordPress

WordPress then processes the request.

Conceptually:
```
WordPress
│
├── Core
├── Theme
├── Plugins
└── Database queries
```
It can generate HTML dynamically.

89. MySQL

WordPress often needs database data:
```
WordPress
 ↓
MySQL
 ↓
posts
users
settings
metadata
options
```
The result comes back:
```
MySQL
 ↓
WordPress
 ↓
PHP-FPM
 ↓
Nginx
```
90. Final HTTP Response

Nginx sends the result back:
```
WordPress
 ↓
HTML
 ↓
Nginx
 ↓
TLS
 ↓
TCP
 ↓
Internet
 ↓
Browser
```
91. Complete Request

This is one of the most important diagrams in your hosting education:
```
                    USER
                     │
                     ▼
                  BROWSER
                     │
                     ▼
                    DNS
                     │
                     ▼
                  IP ADDRESS
                     │
                     ▼
                    TCP
                     │
                     ▼
                    TLS
                     │
                     ▼
                   HTTP
                     │
                     ▼
                  NGINX
                     │
              ┌──────┴──────┐
              │             │
              ▼             ▼
          Static File    PHP-FPM
                            │
                            ▼
                         WordPress
                            │
                            ▼
                           MySQL
                            │
                            ▼
                         Response
                            │
                            ▼
                          NGINX
                            │
                            ▼
                           TLS
                            │
                            ▼
                           TCP
                            │
                            ▼
                         BROWSER
```
92. Practical Command

You can inspect HTTP headers with:
```
curl -I https://templates.cresignsys.com
```
This asks for response headers.

You might see:
```
HTTP/2 200
content-type: text/html
server: nginx
```
The exact output depends on your configuration.

93. Detailed Request

Use:
```
curl -v https://templates.cresignsys.com
```
This is extremely useful because it exposes much of the connection process.

Conceptually:
```
DNS
 ↓
TCP
 ↓
TLS
 ↓
HTTP
```
94. Inspect Only HTTP Headers
```
curl -I https://templates.cresignsys.com/
```
Look for:
```
HTTP status
Content-Type
Cache-Control
Server
Location
Set-Cookie
Content-Encoding
```
95. Inspect Redirects

Use:
```
curl -I -L http://templates.cresignsys.com
```
-L follows redirects.

You may see:
```
HTTP/1.1 301
Location: https://templates.cresignsys.com/
```
followed by:
```
HTTP/2 200
```
96. Test a Specific Path
```
curl -I https://templates.cresignsys.com/wp-login.php
```
This lets you see how a particular endpoint responds.

97. HTTP Error Investigation

If you see:
```
502
```
don’t immediately blame TLS.

The chain is:
```
DNS ✓
TCP ✓
TLS ✓
HTTP ✓
Nginx ✓
PHP-FPM ✗
```
possibly.

If you see:
```
404
```
the problem may be:
```
Nginx routing
WordPress routing
Missing file
Application route
```
98. The Layered Diagnostic Method

Always ask:
```
1. Does DNS resolve?
2. Can I reach the IP?
3. Is TCP 443 reachable?
4. Does TLS succeed?
5. What HTTP status is returned?
6. What does Nginx log?
7. What does PHP-FPM log?
8. What does WordPress report?
9. What does MySQL report?
```
This method will save enormous time when managing your hosting server.

99. The Core HTTP Vocabulary

Memorize:
```
HTTP
=
web application protocol

Request
=
client → server

Response
=
server → client

Method
=
operation requested

Header
=
metadata

Body
=
actual message content

Status code
=
result of request

Cookie
=
client-side state mechanism

Cache
=
stored response/resource

Host
=
requested HTTP hostname
```
100. The Whole Web Hosting Picture

You have now built a much deeper understanding:
```
                     WEB HOSTING
                          │
       ┌──────────────────┼──────────────────┐
       ▼                  ▼                  ▼
      DNS                TCP                TLS
       │                  │                  │
   Name → IP         Reliable stream     Secure channel
                          │                  │
                          └────────┬─────────┘
                                   ▼
                                  HTTP
                                   │
                                   ▼
                                  NGINX
                                   │
                    ┌──────────────┴──────────────┐
                    ▼                             ▼
               Static files                   PHP-FPM
                                                  │
                                                  ▼
                                              WordPress
                                                  │
                                                  ▼
                                                MySQL
```
Lesson 041 Summary

The most important concept is:
```
HTTP = the language used by web applications.
```
A simple request:
```
GET /about HTTP/1.1
Host: templates.cresignsys.com
```
becomes:
```
Browser
 ↓
HTTP
 ↓
TLS encryption
 ↓
TCP
 ↓
IP
 ↓
Internet
 ↓
Nginx
```
Then Nginx decides:
```
Static file?
     ↓
    YES → filesystem

Dynamic?
     ↓
    YES → PHP-FPM → WordPress → MySQL
```
The response travels back through the same lower layers.

Next Lesson — 042

Nginx — From HTTP Request to server {}

We will now enter the actual web-server configuration on your Ubuntu VPS.

We will understand:
```
server {
    listen 443 ssl;
    server_name templates.cresignsys.com;

    root /storage/websites/templates.cresignsys.com/public;

    ssl_certificate ...;
    ssl_certificate_key ...;

    location / {
        ...
    }

    location ~ \.php$ {
        ...
    }
}
```
and trace exactly how Nginx processes:
```
https://templates.cresignsys.com/
https://templates.cresignsys.com/wp-admin/
https://templates.cresignsys.com/wp-login.php
https://templates.cresignsys.com/style.css
```
from TCP connection → TLS → server block → location → filesystem/PHP-FPM → response.
August 13, 2026
CresignSys Learn — Lesson 040
X.509 Certificates — Understanding fullchain.pem From Inside

We now go one level deeper into the certificate itself.

Your server has:
```
/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem
```
and:
```
/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem
```
Today we focus on:
```
fullchain.pem
```
and understand what is actually inside it.

1. What Is a Certificate?

A TLS certificate is a digitally signed data structure that essentially says:

This public key is associated with these identities, subject to these constraints, and this certificate was issued/signed by this authority.

It contains structured information.

It is not simply:
```
SSL = ON
```
2. X.509

The certificate format commonly used by TLS is:

X.509

Think of X.509 as a standardized structure for certificates.

Conceptually:
```
X.509 Certificate
│
├── Identity information
├── Public key
├── Validity period
├── Extensions
└── CA digital signature
```
3. Your Certificate

For:
```
templates.cresignsys.com
```
Let’s inspect it.

Run:
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-text \
-noout
```
This converts the certificate’s binary/DER representation into human-readable information.

4. Why openssl?

OpenSSL is a major open-source cryptographic toolkit.

It can work with:
```
TLS
X.509 certificates
RSA
ECC
Private keys
Hashes
Digital signatures
CSRs
Certificate chains
```
It is extremely useful for server administration.

5. Certificate Encoding

A certificate can be represented in different encodings.

Two important ones are:
```
DER
PEM
```
6. DER

DER is a binary encoding.

If you opened a DER certificate in a text editor, it would not look readable.

Conceptually:
```
Binary bytes
████████████████
```
7. PEM

PEM is a text-based representation containing Base64-encoded binary data.

You commonly see:
```
-----BEGIN CERTIFICATE-----
MIIF...
...
-----END CERTIFICATE-----
```
This is what you will normally encounter in:
```
.pem
```
files.

8. PEM Is Not the Cryptography

This is important.

PEM is primarily an encoding/container representation.

It doesn’t mean:
```
PEM = encryption
```
Instead:
```
X.509 certificate
       ↓
DER binary representation
       ↓
Base64
       ↓
PEM text representation
```
9. Look at the Certificate

Run:
```
sudo head -n 5 \
/etc/letsencrypt/live/templates.cresignsys.com/cert.pem
```
You should see something resembling:
```
-----BEGIN CERTIFICATE-----
MIIF...
...
```
The Base64 characters are an encoded representation of the certificate data.

10. Why Base64?

Base64 converts binary data into printable characters.

It is useful for transporting/storing binary data in text-oriented systems.

But:

Base64 is not encryption.

Anyone can decode it.

11. Base64 Example

Conceptually:
```
Binary
 ↓
Base64
 ↓
Text
```
Then:
```
Text
 ↓
Base64 decode
 ↓
Binary
```
There is no secret involved.

12. Certificate Structure

At a high level:
```
Certificate
│
├── tbsCertificate
│   ├── Version
│   ├── Serial Number
│   ├── Signature Algorithm
│   ├── Issuer
│   ├── Validity
│   ├── Subject
│   ├── Subject Public Key Info
│   └── Extensions
│
├── Signature Algorithm
│
└── Signature Value
```
The exact ASN.1 structure is standardized.

13. ASN.1

You will often encounter:

ASN.1

Abstract Syntax Notation One.

It is a formal language used to describe structured data.

X.509 certificates are defined using ASN.1 structures.

14. DER and ASN.1

A simplified relationship:
```
ASN.1
 ↓
defines structure

DER
 ↓
encodes structure into bytes

PEM
 ↓
Base64/text wrapper around DER
```
This is a useful mental model.

15. Certificate Version

You may see:
```
Version: 3
```
Modern X.509 certificates generally use:
```
X.509 v3
```
The version is important because extensions are heavily used in v3 certificates.

16. Serial Number

The certificate has a:

Serial Number

Conceptually:
```
Certificate
 ↓
Serial Number
```
The CA assigns this identifier.

It helps identify a particular certificate.

17. Issuer

The:

Issuer

identifies the CA that issued the certificate.

Conceptually:
```
Your certificate
       ↓
Issuer
       ↓
Certificate Authority
```
18. Subject

Historically, certificates contain a:

Subject

field identifying the certificate subject.

However, modern TLS hostname verification primarily relies on:

Subject Alternative Name

rather than the old Common Name alone.

19. Common Name

You may see:
```
CN = templates.cresignsys.com
```
The Common Name is historically important.

But modern browsers use SAN for hostname verification.

So don’t rely on CN alone.

20. Subject Alternative Name

You may see:
```
X509v3 Subject Alternative Name:
    DNS:templates.cresignsys.com
```
This is extremely important.

It tells the client which DNS identities the certificate covers.

21. Why SAN Exists

A certificate can cover multiple identities.

For example:
```
DNS:example.com
DNS:www.example.com
DNS:api.example.com
```
The browser can check the requested hostname against the SAN entries.

22. Your Certificate

For your site:
```
templates.cresignsys.com
```
the certificate should contain an appropriate SAN entry for that hostname.

You can check:
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-ext subjectAltName
```
23. Validity Period

A certificate contains:
```
Not Before
Not After
```
Conceptually:
```
Not Before
     ↓
[ Certificate valid ]
     ↓
Not After
```
If the current time is outside the validity period, the certificate is not valid for normal use.

24. Your Let’s Encrypt Certificate

Your Certbot output showed an expiration date of:
```
2026-11-11
```
That is the certificate’s current Not After date reported during issuance.

You can independently check it:
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-dates
```
25. Public Key

The certificate contains:

Subject Public Key Info

Conceptually:
```
Certificate
      │
      ▼
Public Key
```
This is the public half of the server’s asymmetric key pair.

26. Public Key Algorithm

You may see something like:
```
Public Key Algorithm: id-ecPublicKey
```
or:
```
Public Key Algorithm: rsaEncryption
```
This tells you what type of public key is present.

27. ECC Certificate

A modern certificate may use an elliptic-curve public key.

For example:
```
EC Public Key
```
This can be associated with algorithms such as:
```
ECDSA
```
for signatures.

28. RSA Certificate

Another certificate could use:
```
RSA Public Key
```
RSA remains widely supported.

However, TLS 1.3 uses modern key-exchange mechanisms such as ECDHE rather than the old RSA key-exchange mechanism.

29. Certificate Signature

At the bottom conceptually:
```
Certificate data
       ↓
CA private signing key
       ↓
Digital signature
```
The CA signs the certificate.

30. Browser Verification

The browser receives:
```
Certificate
+
Signature
```
It uses the issuer’s trusted public key chain to verify that the certificate was genuinely signed by the expected CA chain.

Conceptually:
```
Certificate
   ↓
CA signature
   ↓
Verify
   ↓
VALID / INVALID
```
31. Certificate Chain

Now we reach one of the most important concepts.

Your server certificate doesn’t normally stand alone.

Conceptually:
```
Root CA
   │
   ▼
Intermediate CA
   │
   ▼
Your server certificate
```
This is called a:

Certificate chain

32. Root CA

The root certificate is the trust anchor.

Browsers/operating systems already contain trusted root certificates.

Conceptually:
```
Browser Trust Store
       │
       ▼
Trusted Root
```
33. Intermediate CA

The root generally signs an intermediate CA certificate.

Then the intermediate signs your server certificate.

Conceptually:
```
Root
 │
 │ signs
 ▼
Intermediate
 │
 │ signs
 ▼
Your certificate
```
34. Why Use Intermediates?

It provides a hierarchy and limits the exposure of root CA private keys.

The root CA can remain more tightly protected while intermediate CAs handle ordinary certificate issuance.

35. Trust Anchor

The browser doesn’t need an infinite chain.

Eventually it reaches a certificate that is already trusted locally:
```
Root CA
```
This is the:

Trust anchor

36. fullchain.pem

Now your file makes sense.

Conceptually:
```
fullchain.pem
│
├── Leaf/server certificate
│
└── Intermediate certificate(s)
```
The exact chain can vary depending on the CA’s current infrastructure.

37. Why Nginx Uses Full Chain

Suppose the server sends:
```
Only server certificate
```
but the client doesn’t already have the required intermediate.

The client might not be able to construct:
```
Server
 ↓
Intermediate
 ↓
Trusted Root
```
Therefore the server generally sends the needed intermediate chain.

38. Server Certificate vs Root

A common mistake is thinking:
```
fullchain.pem
=
root certificate
```
No.

It normally contains:
```
Leaf certificate
+
Intermediate certificate(s)
```
The trusted root is generally already in the client’s trust store.

39. cert.pem

Certbot commonly maintains:
```
cert.pem
```
which represents the server/leaf certificate.

Conceptually:
```
cert.pem
 ↓
templates.cresignsys.com certificate
```
40. chain.pem

This generally represents the intermediate certificate chain.

Conceptually:
```
chain.pem
 ↓
Intermediate CA certificate(s)
```
41. fullchain.pem

Conceptually:
```
fullchain.pem
=
cert.pem
+
chain.pem
```
This is a useful practical mental model.

42. privkey.pem

This is completely different:
```
privkey.pem
 ↓
Private key
```
It isn’t part of the public certificate chain.

43. Certificate vs Private Key

Remember:
```
PUBLIC SIDE
────────────
cert.pem
chain.pem
fullchain.pem

SECRET SIDE
───────────
privkey.pem
```
44. Certificate Extensions

Modern X.509 v3 certificates use extensions extensively.

You may see:
```
X509v3 extensions:
```
These extensions tell clients and systems how the certificate can be used.

45. Key Usage

One important extension is:

Key Usage

It can specify permitted cryptographic purposes.

Examples include:
```
Digital Signature
Key Encipherment
Certificate Sign
CRL Sign
```
The exact values depend on the certificate type.

46. Extended Key Usage

Another is:

Extended Key Usage

For a normal web-server certificate you may see:
```
TLS Web Server Authentication
```
often represented as:
```
serverAuth
```
47. Why EKU Matters

It says, in effect:

This certificate is intended for particular application purposes.

A certificate isn’t necessarily valid for every possible cryptographic use.

48. Basic Constraints

Another important extension:

Basic Constraints

It helps identify whether a certificate can act as a CA.

Conceptually:
```
CA certificate
 ↓
CA:TRUE

Server certificate
 ↓
CA:FALSE
```
49. CA Certificate vs Server Certificate

This distinction is fundamental.

CA certificate

Can participate in signing subordinate certificates.

Server/leaf certificate

Normally identifies a specific server/domain and is not itself a CA.

Conceptually:
```
Root CA
   ↓
Intermediate CA
   ↓
Leaf certificate
```
50. Authority Key Identifier

You may also see:
```
Authority Key Identifier
```
It helps identify the key associated with the certificate issuer.

51. Subject Key Identifier

You may see:
```
Subject Key Identifier
```
It identifies the public key associated with the subject.

These identifiers assist with certificate-chain construction and management.

52. Certificate Policies

Certificates can contain policy information describing the policies under which they were issued.

This becomes more important in enterprise/public PKI environments.

53. CRL Distribution Points

You may encounter:

CRL Distribution Points

CRL means:

Certificate Revocation List

It identifies locations where revocation information may be obtained.

Modern browsers also use other revocation/status mechanisms, including OCSP and related techniques.

54. OCSP

OCSP means:

Online Certificate Status Protocol

It can be used to obtain certificate status information.

Conceptually:
```
Browser
 ↓
OCSP service
 ↓
Certificate status
```
The practical details vary by browser, CA, stapling configuration, and current PKI architecture.

55. Revocation

Suppose a private key is compromised.

The certificate may need to be revoked before its normal expiration.

Conceptually:
```
Certificate
 ↓
Compromised
 ↓
Revoked
```
Revocation mechanisms help clients learn that the certificate should no longer be trusted.

56. Certificate Expiration vs Revocation

Different concepts:
```
Expiration
=
certificate reached its validity end

Revocation
=
certificate was invalidated before normal expiration
```
57. Let’s Encrypt Automation

Now connect X.509 back to Certbot:
```
Certbot
 ↓
ACME
 ↓
Let's Encrypt
 ↓
validation
 ↓
X.509 certificate
 ↓
cert.pem
chain.pem
fullchain.pem
privkey.pem
 ↓
Nginx
```
58. Certificate Signing Request

Before a CA issues a certificate, the applicant commonly creates a:

CSR

Certificate Signing Request.

It contains information such as:
```
Public key
Requested identities
Requested extensions
Signature proving possession of the corresponding private key
```
59. CSR Does Not Contain the Private Key

This is critical.

A CSR contains:
```
PUBLIC KEY
```
and information signed using the corresponding private key.

It does not send the private key to the CA.

Conceptually:
```
Private key
    │
    ├── proves possession
    │
    └── remains with requester

Public key
    │
    ▼
CSR
```
60. CSR Flow

Conceptually:
```
Generate private key
        ↓
Generate public key
        ↓
Create CSR
        ↓
Send CSR to CA
        ↓
Domain validation
        ↓
CA signs certificate
        ↓
Certificate returned
```
61. Private Key Generation

For example, a system might generate:
```
Private Key
```
from secure random data.

The corresponding:
```
Public Key
```
is mathematically derived.

62. Public Key Is Derived From Private Key

Conceptually:
```
Private key
     │
     │ mathematical operation
     ▼
Public key
```
The reverse operation should be computationally infeasible.

This is a central property of asymmetric cryptography.

63. One-Way Relationship

You can distribute:
```
Public key
```
without revealing:
```
Private key
```
The security of the system depends on the underlying mathematical problem being computationally difficult.

64. Certificate Lifecycle

Now you can understand the complete certificate lifecycle:
```
1. Generate private key
          ↓
2. Generate public key
          ↓
3. Create CSR
          ↓
4. Submit to CA
          ↓
5. Prove domain control
          ↓
6. CA signs certificate
          ↓
7. Install certificate
          ↓
8. Nginx serves certificate
          ↓
9. Browser validates
          ↓
10. TLS session established
          ↓
11. Renew before expiration
```
65. Certificate vs TLS Session

Don’t confuse these.

Certificate

Longer-lived identity object:
```
Who is this server/domain?
```
TLS session

Temporary secure communication session:
```
How do we securely communicate right now?
```
66. Certificate Is Not the Session Key

This is one of the deepest distinctions:
```
Certificate
=
identity/authentication information

Session key
=
temporary traffic-protection secret
```
67. Complete Relationship
```
Certificate
   │
   ├── Domain identity
   ├── Public key
   └── CA signature
            │
            ▼
       TLS authentication
            │
            ▼
       ECDHE key exchange
            │
            ▼
       Shared secret
            │
            ▼
           HKDF
            │
            ▼
       Session keys
            │
            ▼
       AES-GCM / ChaCha20
            │
            ▼
       Encrypted HTTP
```
68. Inspect Your Certificate

Run these commands on your VPS.

Full certificate details
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-text \
-noout
```
Subject
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-subject
```
Issuer
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-issuer
```
Dates
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-dates
```
SAN
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-ext subjectAltName
```
69. Inspect the Public Key
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-pubkey
```
You can also inspect key details depending on whether the certificate uses RSA or EC.

70. Check Certificate Fingerprint

A certificate can be represented by a fingerprint.

For example:
```
sudo openssl x509 \
-in /etc/letsencrypt/live/templates.cresignsys.com/cert.pem \
-noout \
-fingerprint \
-sha256
```
This produces a SHA-256 fingerprint.

71. Why Fingerprints Matter

A fingerprint is useful as a compact identifier.

Conceptually:
```
Certificate
 ↓
SHA-256
 ↓
Fingerprint
```
If the certificate changes, the fingerprint generally changes.

72. Inspect the Full Chain

You can see how many certificates are contained in:
```
fullchain.pem
```
For example:
```
grep -c "BEGIN CERTIFICATE" \
/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem
```
If the result is:
```
2
```
there are two PEM certificate blocks in the file.

73. Certificate Chain Visualization

Suppose there are two certificates:
```
fullchain.pem

Certificate 1
   ↓
templates.cresignsys.com

Certificate 2
   ↓
Intermediate CA
```
The browser can use them to build:
```
templates.cresignsys.com
        ↓
Intermediate CA
        ↓
Trusted Root
```
74. Trust Store

Your computer has a collection of trusted CA certificates.

Linux systems may have a CA bundle.

Browsers may use their own trust mechanisms or the operating system depending on platform/browser.

Conceptually:
```
Browser
 ↓
Trust Store
 ↓
Trusted CA roots
```
75. Why Trust Is Central

Without a trusted CA system, anyone could create:
```
templates.cresignsys.com
```
certificate.

The browser needs a trusted mechanism to distinguish:
```
legitimate certificate
```
from:
```
fake certificate
```
76. Public Key Infrastructure

All of this belongs to:

PKI

Public Key Infrastructure.

PKI includes concepts such as:
```
Certificates
Certificate Authorities
Private keys
Public keys
Certificate chains
Trust stores
Certificate issuance
Revocation
Renewal
```
77. Web PKI

HTTPS uses the public Internet’s PKI system.

Conceptually:
```
Browser
 ↓
Trust Store
 ↓
CA
 ↓
Intermediate CA
 ↓
Website certificate
 ↓
Domain
```
This is the trust infrastructure behind ordinary browser HTTPS.

78. Your Hosting Stack Now

You can now see a much deeper architecture:
```
DOMAIN
  ↓
DNS
  ↓
IP
  ↓
TCP
  ↓
TLS
  │
  ├── PKI
  │    ├── CA
  │    ├── Certificate
  │    ├── Chain
  │    └── Trust store
  │
  ├── Cryptography
  │    ├── ECDHE
  │    ├── HKDF
  │    └── AEAD
  │
  └── SNI
       ↓
     NGINX
       ↓
     HTTP
       ↓
   PHP-FPM
       ↓
   WORDPRESS
       ↓
     MYSQL
```
79. Most Important Vocabulary

Memorize:
```
X.509
=
certificate format/standard

PEM
=
text encoding/container representation

DER
=
binary encoding

ASN.1
=
data-structure notation

CSR
=
Certificate Signing Request

CA
=
Certificate Authority

Root
=
trust anchor

Intermediate
=
delegated CA

Leaf
=
server/domain certificate

SAN
=
identities covered by certificate

PKI
=
public-key trust infrastructure
```
80. One Mental Model

Think of your certificate like a digitally signed identity document:
```
Certificate
│
├── "Who?"
│     └── templates.cresignsys.com
│
├── "Which public key?"
│     └── server public key
│
├── "For how long?"
│     └── validity period
│
├── "What can it be used for?"
│     └── extensions
│
└── "Who vouches for it?"
      └── CA signature
```
The browser verifies that document before trusting the server identity.

Lesson 040 Summary

Your:
```
fullchain.pem
```
is essentially the server certificate plus the intermediate chain needed by clients to build trust.

Your:
```
privkey.pem
```
is the corresponding secret private key.

The trust model is:
```
Root CA
   ↓
Intermediate CA
   ↓
templates.cresignsys.com certificate
   ↓
Browser verifies
```
Then TLS uses modern cryptography:
```
Certificate
 ↓
Authentication
 ↓
ECDHE
 ↓
Shared secret
 ↓
HKDF
 ↓
Session keys
 ↓
AES-GCM / ChaCha20-Poly1305
 ↓
Encrypted HTTP
```
And the entire thing runs on top of:
```
TCP
 ↓
IP
 ↓
Internet
```
Next Lesson — 041

HTTP — The Language Nginx and Your Browser Actually Speak

We will now move above TLS and study what happens after the encrypted connection is established:
```
GET / HTTP/1.1
Host: templates.cresignsys.com
User-Agent: ...
Accept: ...
Cookie: ...
```
Then:
```
HTTP request
 ↓
Nginx
 ↓
server_name
 ↓
location
 ↓
static file OR PHP-FPM
 ↓
WordPress
 ↓
HTTP response
 ↓
TLS encryption
 ↓
TCP
 ↓
Browser
```
We will then go deeply into HTTP methods, headers, status codes, cookies, sessions, caching, HTTP/1.1, HTTP/2, HTTP/3, reverse proxying, and how Nginx actually processes a request.
August 13, 2026

CresignSys Learn — Lesson 039

Cryptography From Zero: The Science Behind TLS

We now go one level deeper.

So far:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP

We learned that TLS uses cryptography.

Now we ask:

What is cryptography actually doing mathematically?

1. The Four Fundamental Ideas

Modern web security is built from several different mathematical tools:

Cryptography
│
├── Encryption
├── Hashing
├── Digital signatures
└── Key exchange

They solve different problems.

2. Encryption

Encryption converts readable information:

PLAINTEXT

into protected information:

CIPHERTEXT

Conceptually:

Plaintext
   │
   │ Key
   ▼
Encryption
   │
   ▼
Ciphertext

To recover it:

Ciphertext
   │
   │ Key
   ▼
Decryption
   │
   ▼
Plaintext

3. Example

Suppose:

Plaintext:

HELLO

Encryption might produce:

Ciphertext:

8F4A91...

The ciphertext should not reveal the plaintext to someone who doesn’t possess the necessary key.

The actual algorithms are much more mathematically sophisticated.

4. Two Major Types of Encryption

There are two fundamental categories:

Symmetric encryption
Asymmetric cryptography

5. Symmetric Encryption

Symmetric encryption uses a shared secret key.

             SECRET KEY
                 │
                 ▼
Plaintext → Encryption → Ciphertext
                              │
                              ▼
                         Decryption
                              │
                              ▼
                          Plaintext

The communicating parties need access to the appropriate secret key.

6. Example Symmetric Algorithm

A major modern algorithm is:

AES

Advanced Encryption Standard.

Common configurations include:

AES-128
AES-256

TLS can use AES-GCM constructions.

7. Why AES Is Fast

AES is designed for efficient implementation in software and hardware.

Modern CPUs often have specialized instructions for AES.

Therefore it is suitable for:

Web pages
Images
Videos
API traffic
Database connections
Large files

8. Asymmetric Cryptography

Asymmetric cryptography uses a key pair:

Public key
Private key

Conceptually:

              KEY PAIR
                 │
        ┌────────┴────────┐
        ▼                 ▼
   Public key        Private key

They are mathematically related.

9. Public Key

The public key can be distributed.

For example:

Server
 ↓
Certificate
 ↓
Public key
 ↓
Browser

There is no need to keep the public key secret.

10. Private Key

The private key must remain secret.

Your server has:

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

That is sensitive key material.

11. Why Two Keys?

The key pair allows cryptographic operations where possession of the private key proves control of the corresponding public key.

One major use is:

Digital signatures

12. Digital Signature

A digital signature allows someone to verify:

The holder of the private key authorized this data.

Conceptually:

Data
  │
  ▼
Hash
  │
  ▼
Private key
  │
  ▼
Digital signature

The recipient can use the public key to verify the signature.

13. Signature Verification

Conceptually:

Data
 │
 ▼
Hash ────────────┐
                 │
Signature ───────┤
                 ▼
            Verification
                 │
             VALID / INVALID

The actual mathematical operations depend on the signature algorithm.

14. Digital Signature Is Not Encryption

This distinction is extremely important.

Encryption:

Goal:
Keep information secret

Digital signature:

Goal:
Prove authenticity/integrity

So:

Encryption ≠ Digital signature

15. Hashing

Hashing is another fundamental cryptographic operation.

A hash function takes arbitrary-length input and produces a fixed-size output.

Conceptually:

Input
  │
  ▼
Hash function
  │
  ▼
Digest

16. Example

Suppose:

Input:

Hello

A cryptographic hash produces a digest.

For SHA-256, the output is:

256 bits

or:

32 bytes

usually represented as:

64 hexadecimal characters

17. SHA-256

One important cryptographic hash function is:

SHA-256

SHA means:

Secure Hash Algorithm

SHA-256 produces:

256-bit digest

18. Hash Is Not Encryption

This is a common beginner mistake.

Encryption:

plaintext
 ↓
ciphertext
 ↓
decryption
 ↓
plaintext

Hashing:

input
 ↓
hash
 ↓
digest

A cryptographic hash is designed to be one-way in practice.

19. Why Hashes Are Useful

Hashes can help with:

Integrity verification
Digital signatures
Password storage systems
Certificates
Software verification
Content addressing
Blockchain systems

20. Tiny Change, Huge Difference

A good cryptographic hash has an avalanche effect.

Suppose:

Input A:
Hello

and:

Input B:
hello

Changing one character can produce a dramatically different digest.

Conceptually:

Hello
 ↓
HASH A

hello
 ↓
HASH B

The outputs should look unrelated.

21. Hash Collision

A collision occurs when:

Input A
 ↓
Hash X

Input B
 ↓
Hash X

Cryptographic hash functions are designed to make finding such collisions computationally difficult.

22. SHA-1 vs SHA-256

Older systems may still mention:

SHA-1

but SHA-1 is no longer considered suitable for modern collision-resistant security applications.

Modern systems generally use stronger algorithms such as:

SHA-256
SHA-384
SHA-512

depending on the application.

23. Hashing and Passwords

Passwords are generally not stored as plaintext.

Instead, password systems use password hashing mechanisms.

Conceptually:

User enters password
       ↓
Password hashing
       ↓
Stored password verifier

Modern password storage should use dedicated password hashing algorithms such as:

Argon2
bcrypt
scrypt
PBKDF2

rather than simply storing:

SHA-256(password)

24. Why Password Hashing Is Different

A normal cryptographic hash is designed to be extremely fast.

That’s useful for many applications.

But for password storage, you actually want an attacker to have a harder time trying billions of guesses.

Therefore password hashing algorithms are deliberately:

Computationally expensive
Memory-intensive where appropriate
Salted

25. Salt

A salt is a random value associated with a password hash.

Conceptually:

Password
   +
Random salt
   ↓
Password hashing
   ↓
Verifier

Two users with the same password should not automatically have identical stored password hashes.

26. Salt vs Encryption Key

Don’t confuse:

Salt

with:

Encryption key

A salt is generally not secret.

A private/encryption key is secret.

27. Randomness

Cryptography depends heavily on:

Randomness

Bad randomness can destroy otherwise strong cryptographic systems.

For example:

Weak random number
 ↓
predictable key
 ↓
broken security

Modern operating systems provide cryptographically secure randomness mechanisms.

28. Entropy

Entropy is a way of describing unpredictability.

Conceptually:

Predictable
   ↓
Low entropy

Unpredictable
   ↓
High entropy

Cryptographic keys need sufficient unpredictability.

29. Key Space

Suppose a key has:

128 bits

There are:

2^128

possible bit patterns.

That’s an enormous number.

For a 256-bit key:

2^256

possible values.

30. Why Key Length Matters

A larger key space generally makes brute-force searching harder.

But:

Bigger is not automatically better.

The security depends on the algorithm, implementation, protocol, and threat model.

31. Brute Force

Suppose an attacker doesn’t know a secret key.

They could theoretically try:

Key 1
Key 2
Key 3
...

This is:

Brute-force attack

Good cryptographic systems make exhaustive searching computationally infeasible.

32. Public-Key Algorithms

Two major families you’ll encounter are:

RSA
ECC

33. RSA

RSA is a public-key cryptosystem based on mathematical properties related to large integer factorization.

It has historically been widely used for:

Encryption
Digital signatures
TLS certificates
SSH

Modern TLS 1.3 uses RSA signatures in some certificate configurations, but RSA key exchange itself was removed from TLS 1.3.

34. ECC

ECC means:

Elliptic Curve Cryptography

It uses mathematical structures involving elliptic curves over finite fields.

ECC can provide strong security with comparatively smaller key sizes than traditional RSA.

35. ECDSA

ECDSA means:

Elliptic Curve Digital Signature Algorithm

It is used for digital signatures.

Conceptually:

Private ECC key
      ↓
ECDSA signature
      ↓
Public ECC key
      ↓
Verification

36. ECDHE

ECDHE means:

Elliptic Curve Diffie-Hellman Ephemeral

It is used for key agreement.

Conceptually:

Client ephemeral key
        +
Server ephemeral key
        ↓
Shared secret

The secret itself is not directly transmitted.

37. ECDSA vs ECDHE

This distinction is important:

ECDSA
 ↓
Digital signatures

while:

ECDHE
 ↓
Key agreement

They solve different problems.

38. TLS Uses Several Algorithms Together

A TLS connection can conceptually involve:

Certificate
    ↓
ECDSA/RSA signature
    ↓
Authentication

ECDHE
    ↓
Shared secret

AES-GCM / ChaCha20-Poly1305
    ↓
Application-data encryption

SHA-256-family primitives
    ↓
Hashing / transcript/key-derivation functions

The exact algorithms depend on the TLS configuration.

39. TLS Is a Protocol, Not One Algorithm

This is another major concept.

TLS is not:

"an encryption algorithm"

TLS is a protocol that defines how multiple cryptographic mechanisms work together.

Think:

TLS
├── Authentication
├── Key exchange
├── Key derivation
├── Encryption
├── Integrity protection
└── Protocol state

40. Key Exchange

The browser and server need shared secret material.

But imagine the Internet is being observed.

You cannot simply send:

SECRET KEY

in plaintext.

So TLS uses key agreement.

41. Diffie-Hellman Idea

The fundamental idea:

Client
   │
   │ public information
   ▼
Server

Both sides combine public information with their own secret values.

They independently calculate the same shared secret.

42. Observer

An observer sees:

Client public value
Server public value

but does not know:

Client private value
Server private value

Therefore the observer should not be able to calculate the shared secret under the cryptographic assumptions.

43. Ephemeral Keys

TLS 1.3 normally uses ephemeral key exchange.

Conceptually:

Connection 1
 ↓
Temporary keys

Connection 2
 ↓
Different temporary keys

Connection 3
 ↓
Different temporary keys

This contributes to forward secrecy.

44. Forward Secrecy

Suppose an attacker steals your server’s long-term private key tomorrow.

With properly implemented ephemeral key exchange, previously captured TLS sessions should not automatically become decryptable.

This is called:

Forward secrecy

or:

Perfect Forward Secrecy

in the relevant context.

45. Certificate Private Key

Now return to your server:

privkey.pem

This is associated with your certificate.

It establishes control of the certificate’s public key and supports server authentication/signatures.

It is not simply the bulk encryption key for all traffic.

46. Session Key

During TLS:

ECDHE
 ↓
shared secret
 ↓
TLS key schedule
 ↓
session traffic keys

These session keys protect the actual application data.

47. Key Derivation

The shared secret isn’t simply used directly as:

AES key

TLS 1.3 uses a key schedule based on:

HKDF

48. HKDF

HKDF means:

HMAC-based Extract-and-Expand Key Derivation Function

It derives cryptographically strong keys from input key material.

Conceptually:

Shared secret
      ↓
HKDF
      ↓
Multiple derived secrets
      ↓
Traffic keys

49. HMAC

HMAC means:

Hash-based Message Authentication Code

It combines:

Hash function
+
Secret key

to create an authentication value.

Conceptually:

Message
+
Secret key
 ↓
HMAC
 ↓
Authentication value

50. HMAC vs Hash

Hash:

Message
 ↓
Hash

HMAC:

Message
+
Secret key
 ↓
HMAC

The secret key is what makes HMAC different.

51. AEAD

TLS 1.3 uses:

AEAD

Authenticated Encryption with Associated Data.

AEAD provides:

Confidentiality
+
Integrity/authentication

for protected records.

Examples:

AES-GCM
ChaCha20-Poly1305

52. Associated Data

Some information doesn’t need to be encrypted but should still be authenticated.

AEAD supports:

Encrypted data
+
Authenticated associated data

This is useful in protocol design.

53. The Cryptographic Toolbox

At this point, think of cryptography as a toolbox:

Hash
 ↓
Fingerprint / digest

HMAC
 ↓
Keyed integrity/authentication

Digital signature
 ↓
Publicly verifiable authentication

ECDHE
 ↓
Key agreement

AES-GCM
 ↓
Fast authenticated encryption

ChaCha20-Poly1305
 ↓
Fast authenticated encryption

HKDF
 ↓
Derive session keys

54. TLS Combines the Toolbox

Conceptually:

                  TLS
                   │
       ┌───────────┼────────────┐
       ▼           ▼            ▼
Authentication  Key Exchange  Encryption
       │           │            │
       ▼           ▼            ▼
Certificate      ECDHE        AES-GCM
Signature        HKDF         ChaCha20

55. Certificate Chain Is Also Cryptography

Your Let’s Encrypt certificate is digitally signed.

Conceptually:

Let's Encrypt CA
       │
       │ private signing key
       ▼
Server certificate
       │
       ▼
Browser verifies

The browser trusts the CA through its trust store.

56. Chain of Trust

Imagine:

Root CA
   │
   │ signs
   ▼
Intermediate CA
   │
   │ signs
   ▼
Your certificate

The browser starts from a trusted root and verifies the signatures down the chain.

57. Why an Attacker Can’t Just Create a Certificate

Suppose an attacker creates:

fake certificate

for:

templates.cresignsys.com

The attacker cannot simply make the browser trust it.

The certificate would need to chain to a trusted authority or otherwise be explicitly trusted by the client.

58. Certificate Validation

The browser checks multiple things.

Conceptually:

Certificate
 │
 ├── Is it signed correctly?
 ├── Is the issuer trusted?
 ├── Is it currently valid?
 ├── Does hostname match?
 ├── Are usages appropriate?
 └── Does the chain validate?

If validation fails, the browser warns or blocks depending on the situation.

59. Certificate Expiration

Your certificate has:

notBefore
notAfter

If:

current date > notAfter

the certificate is expired.

The browser can reject it.

60. Domain Name Validation

The browser checks the requested hostname against the certificate’s SAN entries.

For example:

Requested:
templates.cresignsys.com

Certificate:
templates.cresignsys.com

Match:

VALID

61. Wrong Certificate

Suppose Nginx accidentally serves:

shop.cresignsys.com

for:

templates.cresignsys.com

The certificate hostname may not match.

Then the browser can report a certificate-name error.

62. SNI + Certificate Selection

This explains another important hosting concept:

Browser
 ↓
SNI = templates.cresignsys.com
 ↓
Nginx
 ↓
select correct TLS server configuration
 ↓
fullchain.pem
 ↓
certificate for templates.cresignsys.com

63. One IP, Multiple Certificates

A single IP can host:

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

Nginx can serve different certificates based on the requested hostname/SNI.

This is one of the foundations of shared hosting.

64. Why TLS Is Layered

TLS doesn’t replace:

DNS
TCP
HTTP

Instead:

DNS
 ↓
find destination

TCP
 ↓
transport bytes

TLS
 ↓
secure the transport/application data

HTTP
 ↓
web protocol

Each layer has a different job.

65. A Real HTTPS Request

Let’s trace your website:

Browser
   │
   ▼
DNS
   │
   ▼
YOUR PUBLIC IP
   │
   ▼
TCP 443
   │
   ▼
SYN
   │
   ▼
SYN-ACK
   │
   ▼
ACK
   │
   ▼
TLS ClientHello
   │
   │ SNI = templates.cresignsys.com
   ▼
Nginx
   │
   ▼
TLS Certificate
   │
   ▼
Certificate validation
   │
   ▼
ECDHE key exchange
   │
   ▼
HKDF key derivation
   │
   ▼
Session keys
   │
   ▼
Encrypted HTTP

66. Then Nginx

After TLS has established secure communication:

HTTP request
     ↓
Nginx
     ↓
server_name
     ↓
website root

For WordPress:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

67. The Return Path

The response follows the reverse conceptual path:

MySQL / WordPress
       ↓
PHP-FPM
       ↓
Nginx
       ↓
HTTP response
       ↓
TLS encryption
       ↓
TCP
       ↓
IP
       ↓
Internet
       ↓
Browser

68. Why This Matters for Hosting

When you understand cryptography, you can diagnose problems more intelligently.

For example:

DNS error

is not the same as:

TCP error

which is not the same as:

TLS certificate error

which is not the same as:

HTTP 502

69. Four Different Failures

DNS

Domain doesn't resolve

TCP

Connection refused
Connection timed out

TLS

Certificate expired
Hostname mismatch
Untrusted certificate
TLS negotiation failure

HTTP/Application

These belong to different layers.

70. Your `fullchain.pem`

Think of it as:

"Here is my certificate and the intermediate chain needed to establish trust."

71. Your `privkey.pem`

Think of it as:

"This is the secret private key corresponding to my certificate's public key."

Never expose it publicly.

72. Let’s Encrypt

Think of Let’s Encrypt as:

Certificate Authority
+
ACME service

not:

encryption engine

73. Certbot

Think of Certbot as:

ACME client

that automates:

Request
Validation
Download
Installation
Renewal

74. Nginx

Think of Nginx as:

Web server
+
reverse proxy
+
TLS endpoint

among other capabilities.

In your setup, it terminates TLS for the website.

75. TLS Termination

The term:

TLS termination

means the encrypted TLS connection ends at a particular component.

In your basic architecture:

Browser
   │
   │ encrypted TLS
   ▼
Nginx
   │
   │ decrypted HTTP/application handling
   ▼
PHP-FPM

Nginx is therefore the TLS termination point.

76. Reverse Proxy Later

In a more advanced architecture:

Internet
   ↓
Load Balancer
   ↓
Nginx
   ↓
Application

TLS might terminate at the load balancer instead.

This is why understanding TLS termination becomes important in larger hosting systems.

77. The Security Boundary

Suppose TLS terminates at Nginx:

Internet
   │
   │ encrypted
   ▼
Nginx
   │
   │ decrypted
   ▼
PHP-FPM

The traffic between Nginx and PHP-FPM is then no longer the same Internet-facing TLS connection.

For local communication on the same server, that may be acceptable depending on the architecture.

78. Deepest Basic Model

At the deepest conceptual level:

             TRUST
               │
               ▼
          Certificate
               │
               ▼
        Public/Private Keys
               │
               ▼
        Authentication
               │
               ▼
          Key Exchange
               │
               ▼
        Shared Secret
               │
               ▼
           Key Derivation
               │
               ▼
          Session Keys
               │
               ▼
       Authenticated Encryption
               │
               ▼
          Protected Data

That is the cryptographic foundation of HTTPS.

79. Memorize This Table

Technology	Main purpose
Hash	Fixed-length digest
SHA-256	Cryptographic hash
HMAC	Keyed authentication/integrity
RSA	Public-key cryptography/signatures
ECC	Public-key cryptography family
ECDSA	Digital signatures
ECDHE	Key agreement
HKDF	Key derivation
AES-GCM	Authenticated encryption
ChaCha20-Poly1305	Authenticated encryption
X.509	Certificate format/infrastructure
TLS	Secure communication protocol
ACME	Automated certificate management
Let’s Encrypt	Certificate Authority
Certbot	ACME client
Nginx	TLS endpoint/web server

80. One Diagram to Remember

                  HTTPS
                    │
                    ▼
                   TLS
                    │
       ┌────────────┼────────────┐
       │            │            │
       ▼            ▼            ▼
 Certificate     ECDHE         AEAD
       │            │            │
       ▼            ▼            ▼
 Authentication  Key exchange  Encryption
       │            │            │
       └────────────┼────────────┘
                    ▼
               Secure session
                    │
                    ▼
                   HTTP
                    │
                    ▼
                  Nginx

Lesson 039 Summary

The essential concepts are:

Hash
=
fingerprint/digest

Encryption
=
confidentiality

Digital signature
=
authentication + integrity evidence

ECDHE
=
shared-secret key agreement

HKDF
=
derive session keys

AES-GCM / ChaCha20-Poly1305
=
protect application data

Certificate
=
binds an identity to a public key

Let's Encrypt
=
Certificate Authority

Certbot
=
ACME automation client

TLS
=
protocol combining these technologies

And your actual HTTPS system becomes:

DNS
 ↓
TCP
 ↓
TLS
 ├── Certificate
 ├── SNI
 ├── Authentication
 ├── ECDHE
 ├── HKDF
 └── AES-GCM / ChaCha20-Poly1305
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Next Lesson — 040

X.509 Certificates — The Exact Science Behind `fullchain.pem`

We will go inside the certificate itself:

X.509
 ↓
Certificate structure
 ↓
Subject
 ↓
Issuer
 ↓
Serial number
 ↓
Validity
 ↓
Subject Alternative Name
 ↓
Public key
 ↓
Key usage
 ↓
Extended key usage
 ↓
Basic constraints
 ↓
CA signature
 ↓
Root certificate
 ↓
Intermediate certificate
 ↓
Leaf/server certificate
 ↓
fullchain.pem

Then we will inspect your actual certificate with openssl and understand every important field that appears inside it.

August 13, 2026

CresignSys Learn — Lesson 038
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.
August 13, 2026
CresignSys Learn — Lesson 037
TCP — Deepest Basics

We now go one layer deeper.

Previously:
```
Domain
 ↓
DNS
 ↓
IP address
 ↓
TCP
```
Now we study exactly what TCP does.

1. What Is TCP?

TCP means:

Transmission Control Protocol

TCP is a transport-layer protocol.

Its job is to provide a reliable, ordered stream of bytes between applications.

For example:
```
Browser
   ↓
TCP connection
   ↓
Nginx
```
2. TCP Is Not HTTP

This distinction is essential.
```
HTTP
 ↓
uses TCP
```
HTTP describes:

What request and response are being exchanged.

TCP describes:

How a reliable byte stream is transported between two endpoints.

Therefore:
```
HTTPS
 ↓
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
```
3. TCP Has No Idea What a Web Page Is

TCP does not understand:
```
WordPress
HTML
CSS
PHP
URL
```
TCP sees a stream of bytes.

Conceptually:
```
Application
     ↓
bytes
     ↓
TCP
     ↓
network
```
4. TCP Endpoint

A TCP endpoint can be thought of as:
```
IP address + TCP port
```
For example:
```
203.0.113.50:443
```
means:
```
IP   = 203.0.113.50
Port = 443
```
The IP identifies the network endpoint.

The port identifies the transport endpoint/application service.

5. Client and Server

For your website:
```
Browser
   ↓
Client
```
and:
```
Nginx
   ↓
Server
```
The client initiates the TCP connection.

The server listens for incoming connections.

6. Listening

Nginx may be listening on:
```
TCP :443
```
Check:
```
sudo ss -lntp
```
Conceptually:
```
Nginx
  ↓
LISTEN
  ↓
0.0.0.0:443
```
7. What Happens When the Browser Connects?

Suppose DNS returned:
```
203.0.113.50
```
The browser wants:
```
203.0.113.50:443
```
TCP begins the connection process.

8. TCP Three-Way Handshake

TCP traditionally establishes a connection using:
```
SYN
SYN-ACK
ACK
```
Diagram:
```
Client                         Server

  SYN  ───────────────────────►

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

  ACK  ───────────────────────►
```
This is the famous:

Three-way handshake

9. Why a Handshake?

TCP needs both sides to establish connection state.

It allows the endpoints to synchronize important sequence-number state and confirm that communication is possible.

10. SYN

SYN means the client is initiating a TCP connection.

Conceptually:
```
Client
  │
  │ SYN
  ▼
Server
```
The packet contains TCP control information, including an initial sequence number.

11. Sequence Number

TCP numbers bytes in its stream.

Imagine the client sends:
```
ABCDEFGH
```
TCP conceptually tracks where those bytes belong in the stream.

This allows TCP to:
```
Detect missing data
Reorder segments
Acknowledge received data
```
12. Initial Sequence Number

At connection establishment, each side chooses an initial sequence number.

For example, conceptually:
```
Client:
ISN = 1000

Server:
ISN = 5000
```
The actual values are not normally this predictable.

The important idea is:
```
Each direction has its own sequence-number space.
```
13. SYN-ACK

The server responds:
```
SYN + ACK
```
Conceptually:
```
Client
  │
  │ SYN, Seq=1000
  ▼
Server
  │
  │ SYN-ACK
  │ Seq=5000
  │ Ack=1001
  ▼
Client
```
Why Ack=1001?

Because the SYN consumes one sequence-number position.

14. ACK

The client responds:
```
ACK
```
Conceptually:
```
Client
  │
  │ ACK = 5001
  ▼
Server
```
Now both sides have established the TCP connection.

15. Then TLS Starts

For HTTPS over TCP:
```
TCP handshake
       ↓
TLS handshake
       ↓
HTTP
```
So:
```
SYN
 ↓
SYN-ACK
 ↓
ACK
 ↓
TLS ClientHello
```
16. TCP Connection Is a State Machine

TCP isn’t simply:
```
connected
```
or:
```
not connected
```
It has multiple states.

Examples:
```
LISTEN
SYN-SENT
SYN-RECEIVED
ESTABLISHED
FIN-WAIT
CLOSE-WAIT
TIME-WAIT
```
17. LISTEN

A server waiting for connections is commonly in:
```
LISTEN
```
For example:
```
Nginx
 ↓
TCP :443
 ↓
LISTEN
```
18. SYN-SENT

The client sends SYN.

It enters a state conceptually associated with:
```
SYN-SENT
```
while waiting for the server’s response.

19. SYN-RECEIVED

The server receives SYN and sends SYN-ACK.

It can enter:
```
SYN-RECEIVED
```
while completing the handshake.

20. ESTABLISHED

After the handshake:
```
ESTABLISHED
```
means the TCP connection is established.

This is where most application data transfer occurs.

21. Check Established Connections

On your VPS:
```
sudo ss -ntp
```
You may see:
```
ESTAB
```
for active connections.

22. TCP Is a Byte Stream

This is a very important concept.

Suppose an application sends:
```
HELLO
```
then:
```
WORLD
```
TCP doesn’t preserve “HELLO” and “WORLD” as application messages.

It provides:
```
HELLOWORLD
```
as an ordered byte stream.

The application protocol determines message boundaries.

23. TCP Segments

TCP breaks the stream into transport segments.

Conceptually:
```
Application data
      ↓
TCP
      ↓
Segment 1
Segment 2
Segment 3
...
```
IP then carries these segments in packets.

24. TCP Segment

Simplified:
```
┌──────────────────────┐
│ TCP Header           │
├──────────────────────┤
│ Application Payload  │
└──────────────────────┘
```
The TCP header contains information such as:
```
Source port
Destination port
Sequence number
Acknowledgement number
Flags
Window
Checksum
```
plus additional fields/options.

25. IP Packet

TCP sits inside IP.

Conceptually:
```
┌─────────────────────────┐
│ IP Header               │
├─────────────────────────┤
│ TCP Header              │
├─────────────────────────┤
│ Data                    │
└─────────────────────────┘
```
This is called:

Encapsulation

26. Encapsulation

Each layer adds its own information.

Conceptually:
```
HTTP data
   ↓
TLS record/data
   ↓
TCP segment
   ↓
IP packet
   ↓
Link-layer frame
```
At the receiving side, the layers are processed in reverse.

27. Receiving Side

Conceptually:
```
Network frame
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
```
This is called:

Decapsulation

28. Acknowledgements

TCP uses acknowledgements to let the sender know what data has been received.

Conceptually:
```
Client
   │
   │ data
   ▼
Server
   │
   │ ACK
   ▼
Client
```
29. Lost Packet

Suppose:
```
Segment 1 ✓
Segment 2 ✗
Segment 3 ✓
```
The receiver can indicate what data it has successfully received.

The sender can then retransmit missing data.

This is one of the reasons TCP is reliable.

30. TCP Retransmission

Conceptually:
```
Sender
  │
  │ Segment 2
  X
  │
  │  lost
  │
  │ timeout / duplicate ACK mechanisms
  ▼
Retransmit Segment 2
  │
  ▼
Receiver
```
TCP has sophisticated mechanisms for detecting loss and retransmitting data.

31. Why TCP Is Reliable

TCP provides mechanisms for:
```
Ordering
Acknowledgement
Retransmission
Duplicate detection
Flow control
Congestion control
```
This does not mean TCP guarantees successful delivery under every circumstance. A connection can fail.

32. Ordering

Imagine packets arrive:
```
3
1
2
```
TCP can reconstruct the byte stream:
```
1
2
3
```
before delivering the appropriate ordered stream to the application.

33. Duplicate Data

Sometimes retransmission can cause duplicate segments to arrive.

TCP uses sequence numbers to recognize duplicate data.

Conceptually:
```
Sequence number
       ↓
"This byte range has already been received."
```
34. Flow Control

Suppose the server can process data slowly while the client sends very quickly.

The receiver needs a mechanism to tell the sender:

Don’t send more than I can currently handle.

This is:

Flow control

TCP uses a receive window for this purpose.

35. Receive Window

Conceptually:
```
Receiver
   ↓
"I can currently accept this much data."
   ↓
Sender
```
The advertised receive window helps prevent overwhelming the receiver’s available receive buffer.

36. Congestion Control

Flow control protects the receiver.

Congestion control protects the network.

These are different.

Flow control
```
Protect receiver
```
Congestion control
```
Avoid overwhelming the network
```
37. Why Congestion Control Matters

Imagine:
```
1 sender
```
sending moderately.

Then:
```
100,000 senders
```
all send as fast as possible.

The network could become congested.

TCP therefore adjusts sending behavior based on network conditions.

38. Congestion Window

TCP maintains a concept called:

Congestion window

Often abbreviated:
```
cwnd
```
It controls how much unacknowledged data can be in flight based on congestion-control state.

The algorithms are sophisticated.

39. Slow Start

One well-known TCP behavior is:

Slow Start

Despite the name, it can grow quickly.

Conceptually:
```
small sending window
        ↓
increase
        ↓
increase
        ↓
increase
```
until congestion or another limit is encountered.

40. TCP Is Not Always the Same

Different operating systems and TCP implementations can use different congestion-control algorithms.

Examples include:
```
CUBIC
BBR
```
Linux supports configurable congestion-control algorithms.

41. Check TCP Congestion Control

On Linux, you can inspect the configured algorithm with:
```
sysctl net.ipv4.tcp_congestion_control
```
You may see something such as:
```
cubic
```
The exact value depends on your system.

42. TCP Buffering

TCP uses buffers.

Conceptually:
```
Application
 ↓
send buffer
 ↓
TCP
 ↓
network
 ↓
TCP
 ↓
receive buffer
 ↓
Application
```
This allows the application and network to operate somewhat independently.

43. TCP Send Buffer

Nginx may write data to a socket.

The kernel manages sending that data through TCP.

Conceptually:
```
Nginx
 ↓
socket
 ↓
TCP send buffer
 ↓
network
```
Nginx doesn’t manually construct every Ethernet frame.

44. TCP Receive Buffer

Similarly:
```
network
 ↓
TCP
 ↓
receive buffer
 ↓
Nginx
```
The kernel manages much of this process.

45. Socket Is the Application Interface

This is an important bridge:
```
Nginx
 ↓
socket API
 ↓
Linux kernel
 ↓
TCP
 ↓
IP
 ↓
network interface
```
Applications don’t normally manipulate TCP internals directly.

46. connect()

A client application can request a TCP connection through a system-call interface such as:
```
connect()
```
Conceptually:
```
Browser
 ↓
connect(server:443)
 ↓
kernel
 ↓
TCP handshake
```
47. bind()

A server can associate a socket with an address/port using:
```
bind()
```
Conceptually:
```
Nginx
 ↓
bind()
 ↓
:443
```
48. listen()

The server then makes the socket listen:
```
listen()
```
Conceptually:
```
bind
 ↓
listen
 ↓
wait for connections
```
49. accept()

When a connection arrives:
```
accept()
```
can create/access the connected socket for the application.

Conceptually:
```
Listening socket
       ↓
accept()
       ↓
Connected socket
```
50. Your Nginx Server

A simplified representation:
```
Nginx
 │
 ├── listening socket :80
 │
 └── listening socket :443
```
Incoming client connections then become individual connected sockets.

51. TCP Port 443

Your HTTPS architecture is therefore:
```
Internet
 ↓
IP address
 ↓
TCP
 ↓
destination port 443
 ↓
Nginx listening socket
```
Then:
```
TCP connection
 ↓
TLS
 ↓
HTTP
```
52. Connection Refused

Now we can understand an important error.

Suppose the network path works, but nothing is listening on port 443.

The connection can be actively rejected.

You may see:
```
Connection refused
```
Conceptually:
```
Client
 ↓
TCP SYN
 ↓
Server
 ↓
no listener
 ↓
connection rejected
```
53. Connection Timeout

A timeout is different.

Suppose packets cannot reach the server or responses are filtered.

The client may keep waiting.

Eventually:
```
Connection timed out
```
Conceptually:
```
Client
 ↓
SYN
 X
```
with no usable response.

Possible causes include:
```
Cloud firewall
Host firewall
Routing
Network outage
Wrong IP
Server unavailable
```
54. Connection Reset

Another error:
```
Connection reset
```
usually means the connection was forcibly terminated rather than simply receiving no response.

Possible causes include:
```
Application
Firewall
Kernel
Proxy/load balancer
Network equipment
```
The exact cause requires investigation.

55. Three Different Problems

Memorize:
```
Connection refused
=
connection reached a point where it was actively rejected

Connection timed out
=
expected communication did not arrive in time

Connection reset
=
existing/attempted connection was forcibly terminated
```
These clues help identify which layer to investigate.

56. TCP FIN

TCP connections need to close gracefully.

One side can send:
```
FIN
```
meaning approximately:

I have finished sending data.

57. TCP Connection Closing

A simplified four-message close can look like:
```
Client                    Server

FIN       ───────────────►

          ◄────────────── ACK

          ◄────────────── FIN

ACK       ───────────────►
```
The actual behavior can vary depending on which side initiates closure and application state.

58. FIN vs RST

Two important TCP mechanisms:
```
FIN
=
orderly connection shutdown

RST
=
abrupt/reset connection
```
59. TIME-WAIT

After a TCP connection closes, one side can enter:
```
TIME-WAIT
```
This exists for important protocol reasons, including preventing delayed packets from an old connection from interfering with a later connection using the same tuple.

60. Why TIME-WAIT Exists

Imagine:
```
Old connection
 ↓
delayed packet
```
Then a new connection reuses the same connection identifiers.

Without appropriate safeguards, an old delayed packet could potentially be mistaken for part of the new connection.

TIME-WAIT helps prevent this.

61. Check TIME-WAIT

You can inspect:
```
sudo ss -ant state time-wait
```
On a busy web server you may see many entries.

That isn’t automatically a problem.

62. CLOSE-WAIT

Another state you may encounter:
```
CLOSE-WAIT
```
It means the remote side has closed its sending direction, but the local application has not yet fully closed its socket.

Large numbers of long-lived CLOSE-WAIT connections can sometimes indicate application/socket handling problems.

63. TCP Connection Lifecycle

Simplified:
```
LISTEN
   ↓
SYN
   ↓
SYN-RECEIVED
   ↓
ESTABLISHED
   ↓
data transfer
   ↓
FIN
   ↓
closing states
   ↓
TIME-WAIT
   ↓
closed
```
The exact state transitions depend on which endpoint initiates each action.

64. TCP vs UDP

Let’s make the distinction clear.

TCP
```
Connection-oriented
Reliable
Ordered
Byte stream
Retransmission
Flow control
Congestion control
```
UDP
```
Datagram-oriented
No built-in reliable delivery
No built-in ordering
No TCP-style connection establishment
```
65. Why HTTPS Traditionally Uses TCP

Traditional HTTP/1.1 and HTTP/2 deployments commonly use:
```
HTTPS
 ↓
TLS
 ↓
TCP
```
HTTP/3 is different.

It uses:
```
HTTP/3
 ↓
QUIC
 ↓
UDP
```
We will study that later.

66. TCP and TLS Relationship

TLS doesn’t replace TCP.

They have different responsibilities.
```
TLS
 ↓
secure application data

TCP
 ↓
reliable transport
```
So:
```
HTTPS
=
HTTP
+
TLS
+
TCP
```
67. TCP and IP Relationship

IP doesn’t guarantee reliable delivery.

IP primarily provides packet addressing/routing.

TCP adds reliability and connection semantics above IP.

Conceptually:
```
Application
 ↓
TCP
 ↓
IP
 ↓
Network
```
68. IP Can Lose Packets

IP itself does not promise:
```
"Every packet will arrive."
```
Packets can be:
```
Dropped
Delayed
Duplicated
Reordered
```
TCP handles many of these issues for its byte stream.

69. Example: Packet Loss

Suppose your website sends:
```
100 TCP segments
```
and one gets lost.

TCP can detect the missing data and retransmit it.

The application generally doesn’t need to know that a particular TCP segment was lost.

70. But TCP Doesn’t Fix Everything

If the network is completely unavailable:
```
Client
 X
Server
```
TCP cannot magically repair the network.

Eventually the connection fails.

TCP reliability exists within the limits of an operating network path.

71. TCP Latency

Every network communication has latency.

For example:
```
Client
 ↓
Internet
 ↓
Server
```
takes time.

The TCP handshake adds connection-establishment latency.

TLS then adds handshake processing/round trips.

Modern protocols optimize these costs.

72. Round-Trip Time

RTT means:

Round-Trip Time

Conceptually:
```
Client
  ↓
Server
  ↑
Client
```
The time for that round trip is RTT.

73. Why RTT Matters

Suppose:
```
RTT = 10 ms
```
versus:
```
RTT = 200 ms
```
Interactive communication feels very different.

For web hosting, RTT affects connection setup, TLS, and data transfer behavior.

74. TCP Handshake + TLS

For a traditional HTTPS connection, conceptually:
```
DNS
 ↓
TCP handshake
 ↓
TLS handshake
 ↓
HTTP request
```
Therefore several network exchanges can occur before the server sends the actual page.

TLS 1.3 reduces handshake overhead compared with older TLS versions.

75. Connection Reuse

HTTP can reuse an established TCP/TLS connection.

Instead of:
```
Request 1
 ↓
new TCP
 ↓
new TLS

Request 2
 ↓
new TCP
 ↓
new TLS
```
the browser can often do:
```
TCP
 ↓
TLS
 ↓
Request 1
Request 2
Request 3
Request 4
```
This is much more efficient.

76. HTTP Keep-Alive

HTTP connection persistence allows connections to be reused.

This reduces repeated:
```
TCP handshake
TLS handshake
```
costs.

77. HTTP/2

HTTP/2 can multiplex multiple HTTP streams over one TCP connection.

Conceptually:
```
One TCP connection
       │
       ├── Request A
       ├── Request B
       ├── Request C
       └── Request D
```
This is a major improvement over opening a separate connection for every resource.

78. But TCP Has Head-of-Line Effects

Because TCP provides one ordered byte stream, loss of a TCP segment can delay delivery of later bytes to applications even if those later bytes have already arrived.

HTTP/2 over TCP can therefore experience a form of transport-level head-of-line blocking.

This is one reason QUIC/HTTP/3 was developed.

79. QUIC

QUIC is a modern transport protocol built over UDP.

Conceptually:
```
HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP
```
QUIC provides transport features such as:
```
Reliable streams
Encryption integration
Congestion control
Connection migration
```
We will study this in a later lesson.

80. Your Website Today

When you access:
```
https://templates.cresignsys.com
```
a simplified traditional path is:
```
DNS
 ↓
IP
 ↓
TCP :443
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
```
Then:
```
Nginx
 ↓
static file
```
or:
```
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
81. Practical TCP Investigation

Run:
```
sudo ss -lntp
```
Look for:
```
:80
:443
```
Then:
```
sudo ss -ntp
```
Look for:
```
ESTAB
```
82. Check Nginx
```
sudo systemctl status nginx
```
Then:
```
sudo ss -lntp | grep ':443'
```
You want to understand:
```
Nginx
 ↓
listening
 ↓
443
```
83. Test the TCP Port

From another machine, you can test whether TCP 443 is reachable.

For example:
```
nc -vz templates.cresignsys.com 443
```
If nc is installed.

This tests TCP connectivity, not whether the entire HTTPS application is functioning correctly.

84. Test HTTPS

Then:
```
curl -v https://templates.cresignsys.com
```
This goes further:
```
DNS
 ↓
TCP
 ↓
TLS
 ↓
HTTP
```
So curl -v is a valuable diagnostic tool.

85. The Diagnostic Ladder

When troubleshooting a website:
```
Layer 1
DNS
 ↓
Layer 2
IP routing
 ↓
Layer 3
TCP 443
 ↓
Layer 4
TLS
 ↓
Layer 5
HTTP
 ↓
Layer 6
Nginx
 ↓
Layer 7
PHP-FPM
 ↓
Layer 8
WordPress
 ↓
Layer 9
MySQL
```
This layered thinking is much more useful than randomly restarting services.

86. The Deep Mental Model

Think of TCP as a conversation channel.
```
Browser
   │
   │  "Can we communicate?"
   ▼
Server

Browser
   │
   │  "I sent bytes 1000–1999."
   ▼
Server

Server
   │
   │  "I received them."
   ▼
Browser
```
TCP keeps track of this communication state.

87. Most Important TCP Concepts

Memorize these:
```
TCP
=
reliable ordered byte stream

SYN
=
start connection

SYN-ACK
=
server response to connection initiation

ACK
=
acknowledgement

Sequence number
=
tracks byte position

Retransmission
=
recover lost data

Flow control
=
protect receiver

Congestion control
=
protect network

FIN
=
orderly shutdown

RST
=
connection reset
```
88. TCP Error Vocabulary
```
TIMEOUT
=
no usable response within expected time

REFUSED
=
connection actively rejected

RESET
=
connection forcibly terminated

CLOSE-WAIT
=
remote closed, local application hasn't fully closed

TIME-WAIT
=
connection remains temporarily in a closing state
```
These terms become extremely useful when diagnosing VPS problems.

89. Complete Current Knowledge Map

You have now reached:
```
                         WEBSITE
                            │
                            ▼
                       DOMAIN NAME
                            │
                            ▼
                           DNS
                            │
                            ▼
                         IP ADDRESS
                            │
                            ▼
                         ROUTING
                            │
                            ▼
                           TCP
                            │
                            ▼
                           TLS
                            │
                            ▼
                          HTTP
                            │
                            ▼
                          NGINX
                            │
                  ┌─────────┴─────────┐
                  ▼                   ▼
              Static file          PHP-FPM
                                      │
                                      ▼
                                  WordPress
                                      │
                                      ▼
                                    MySQL
```
And underneath all of this:
```
                    LINUX KERNEL
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
       Network          Memory       Filesystem
          │              │              │
          ▼              ▼              ▼
         TCP           RAM/VM        Storage
```
Lesson 037 Summary

The central idea:

TCP takes an unreliable packet-delivery system such as IP and provides applications with a reliable, ordered byte stream.

For your HTTPS website:
```
DNS
 ↓
IP
 ↓
TCP 443
 ↓
3-way handshake
 ↓
TLS handshake
 ↓
HTTP
 ↓
Nginx
```
The TCP handshake:
```
Client                     Nginx

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

        ESTABLISHED
```
Then the actual HTTPS communication begins.

Next Lesson — 038

TLS 1.3 — Deep Cryptographic Basics

We will now return to the SSL/TLS topic and go much deeper:
```
TCP
 ↓
TLS ClientHello
 ↓
ServerHello
 ↓
Cipher suites
 ↓
Key exchange
 ↓
ECDHE
 ↓
Public/private keys
 ↓
Digital signatures
 ↓
Certificate
 ↓
Certificate chain
 ↓
Certificate Authority
 ↓
Let's Encrypt
 ↓
Session keys
 ↓
AES-GCM / ChaCha20-Poly1305
 ↓
Encrypted HTTP
```
Then we will trace the exact role of your fullchain.pem and privkey.pem files inside Nginx during the TLS handshake.
August 13, 2026
CresignSys Learn — Lesson 036
DNS — From templates.cresignsys.com to Your VPS

We now go one layer earlier than TCP/TLS.

When a user enters:
```
https://templates.cresignsys.com
```
the browser first needs to answer:

Where is templates.cresignsys.com?

That is the job of DNS.

1. What DNS Really Does

DNS means:

Domain Name System

Its basic purpose is to translate names into information used by network applications.

The simplest example:
```
templates.cresignsys.com
        ↓
IP address
```
For example, conceptually:
```
templates.cresignsys.com
        ↓
203.0.113.50
```
The IP above is only an example.

Your actual public IP is whatever is currently configured for the domain.

2. Why DNS Exists

Computers communicate using network addresses.

Humans prefer names.

Compare:
```
203.0.113.50
```
with:
```
templates.cresignsys.com
```
A domain name is easier to remember and manage.

DNS provides the mapping system.

3. DNS Is Not the Internet

DNS is one service operating over the Internet.

Don’t think:
```
DNS = Internet
```
Think:
```
Internet
├── DNS
├── HTTP
├── HTTPS
├── SMTP
├── SSH
└── many other protocols
```
4. Domain Name Structure

Take:
```
templates.cresignsys.com
```
Break it down:
```
templates
   .
cresignsys
   .
com
```
There are multiple levels.

5. Root of DNS

At the very top is the:

DNS Root

Conceptually:
```
.
```
Then:
```
.
└── com
```
Then:
```
.
└── com
    └── cresignsys
```
Then:
```
.
└── com
    └── cresignsys
        └── templates
```
The final dot is normally hidden in everyday domain names.

6. Fully Qualified Domain Name

Technically:
```
templates.cresignsys.com.
```
is a fully qualified domain name.

The final:
```
.
```
represents the DNS root.

Browsers and DNS tools normally allow you to omit it.

7. TLD

.com is a:

Top-Level Domain

Examples:
```
.com
.org
.net
.in
.edu
```
There are many more modern TLDs.

8. Second-Level Domain

In:
```
cresignsys.com
```
the:
```
cresignsys
```
portion is the second-level domain under .com.

9. Subdomain

In:
```
templates.cresignsys.com
```
the:
```
templates
```
portion is a subdomain label.

Other examples from your hosting architecture:
```
learn.cresignsys.com
shop.cresignsys.com
templates.cresignsys.com
```
These are separate DNS names under:
```
cresignsys.com
```
10. DNS Names Are Hierarchical

Think:
```
DNS Root
   ↓
.com
   ↓
cresignsys.com
   ↓
templates.cresignsys.com
```
This hierarchy is fundamental to understanding DNS.

11. Registrar

When you register:
```
cresignsys.com
```
you normally do so through a:

Domain Registrar

The registrar handles domain registration and related management.

Examples include many commercial registrars.

The registrar is not necessarily the same company that hosts your website.

12. Registrar vs DNS Provider

These are different concepts.

Registrar

Manages the domain registration.

DNS provider

Hosts/manages the DNS zone and authoritative DNS service.

They can be the same company or different companies.

13. DNS Zone

A DNS zone contains DNS records for a domain or part of the DNS namespace.

For example, a simplified zone for:
```
cresignsys.com
```
might contain:
```
cresignsys.com
www.cresignsys.com
templates.cresignsys.com
mail.cresignsys.com
```
with different records.

14. DNS Records

DNS doesn’t only store IP addresses.

It supports many record types.

Important ones:
```
A
AAAA
CNAME
MX
TXT
NS
SOA
CAA
```
We will study each.

15. A Record

The most important record for a basic IPv4 website is:

A

An A record maps a hostname to an IPv4 address.

Conceptually:
```
templates.cresignsys.com
        ↓
A
        ↓
203.0.113.50
```
16. AAAA Record

An:

AAAA

record maps a hostname to an IPv6 address.

Conceptually:
```
templates.cresignsys.com
        ↓
AAAA
        ↓
2001:db8::50
```
Again, that IPv6 address is an example.

17. A vs AAAA

Remember:
```
A
 ↓
IPv4

AAAA
 ↓
IPv6
```
A domain can have both.

18. CNAME

CNAME means:

Canonical Name

It creates an alias from one DNS name to another DNS name.

For example:
```
www.example.com
      ↓
CNAME
      ↓
example.com
```
The DNS resolver then follows the canonical name.

19. CNAME Is Not an IP Record

This is important.

An A record:
```
name → IPv4
```
A CNAME:
```
name → another name
```
For example:
```
cdn.example.com
      ↓
CNAME
      ↓
provider.example.net
```
20. MX

MX means:

Mail Exchange

It tells mail systems which servers handle email for a domain.

For example:
```
cresignsys.com
      ↓
MX
      ↓
mail provider
```
This does not control your website.

21. TXT

TXT records contain text data used for various purposes.

Common uses include:
```
Domain verification
SPF
DKIM-related configuration
DMARC-related mechanisms
Certificate authority policies
```
The exact syntax depends on the purpose.

22. NS

NS means:

Name Server

NS records identify authoritative nameservers for a DNS zone.

Conceptually:
```
cresignsys.com
      ↓
NS
      ↓
ns1.provider.example
ns2.provider.example
```
23. SOA

SOA means:

Start of Authority

It contains administrative information about the DNS zone.

It includes things such as:
```
Primary/authoritative server information
Zone serial
Refresh
Retry
Expire
Negative caching TTL
```
The exact semantics are part of DNS zone management.

24. CAA

CAA means:

Certification Authority Authorization

It can specify which certificate authorities are authorized to issue certificates for a domain.

For example, a domain owner may configure a CAA record to authorize a particular CA.

This can be useful as an additional control around certificate issuance.

25. Your HTTPS Domain

For:
```
templates.cresignsys.com
```
you might have something conceptually like:
```
templates.cresignsys.com
        ↓
A
        ↓
YOUR VPS PUBLIC IPv4
```
Then:
```
Browser
 ↓
DNS
 ↓
VPS IP
 ↓
TCP 443
```
26. DNS Lookup Does Not Connect to Nginx

This distinction is important.

DNS answers:

What DNS information corresponds to this name?

DNS does not itself establish the HTTPS connection.

The sequence is:
```
DNS lookup
     ↓
IP address obtained
     ↓
TCP connection
     ↓
TLS
     ↓
HTTP
```
27. DNS Resolver

Your browser doesn’t necessarily contact the authoritative DNS server directly.

It commonly asks a:

Recursive DNS Resolver

Examples include resolver services operated by:
```
ISPs
public DNS providers
organizations
local networks
```
28. Recursive Resolver

The resolver’s job is roughly:

Find the answer for this DNS query, using DNS hierarchy and caching.

Conceptually:
```
Browser
 ↓
Recursive resolver
 ↓
DNS hierarchy
 ↓
Answer
 ↓
Browser
```
29. DNS Cache

DNS results are cached.

Suppose the resolver previously learned:
```
templates.cresignsys.com
        ↓
203.0.113.50
```
It may keep that answer for a period determined by the record’s TTL.

Then another user may receive the cached answer without the resolver needing to repeat the entire lookup.

30. TTL

TTL means:

Time To Live

A DNS record can have a TTL such as:
```
300
```
meaning roughly:
```
300 seconds
=
5 minutes
```
The exact caching behavior can involve additional considerations.

31. Why TTL Matters

Suppose:
```
Old IP
 ↓
203.0.113.50
```
and you change it to:
```
New IP
 ↓
203.0.113.60
```
Existing cached DNS answers may continue to be used until their TTL expires.

Therefore DNS changes aren’t necessarily visible everywhere immediately.

32. DNS Propagation

People often say:

DNS propagation takes 24–48 hours.

This is an oversimplification.

More accurately:

Different caches may retain the previous answer until their applicable TTLs expire, while resolver behavior and other factors can affect when users observe the change.

DNS doesn’t literally send a new record around the world.

33. Authoritative Nameserver

An authoritative nameserver is a server that has authoritative information for a DNS zone.

For example:
```
cresignsys.com
        ↓
authoritative DNS servers
        ↓
records
```
The authoritative server is the source of truth for the zone.

34. Root Servers

At the top of the DNS hierarchy are:

Root DNS servers

They don’t normally tell the resolver:
```
templates.cresignsys.com → VPS IP
```
Instead, they help direct the resolver toward the appropriate TLD nameservers.

35. TLD Nameservers

For .com domains, the resolver can be directed to the .com TLD nameservers.

Conceptually:
```
Root
 ↓
.com TLD
 ↓
cresignsys.com authoritative DNS
```
36. Full Recursive Lookup

Suppose the resolver has no cached answer.

The simplified process is:
```
Browser
   ↓
Recursive Resolver
   ↓
Root
   ↓
.com TLD
   ↓
cresignsys.com authoritative nameserver
   ↓
templates.cresignsys.com
   ↓
IP address
```
Then the resolver returns the answer to the browser.

37. The Root Doesn’t Know Everything

The DNS root doesn’t store every domain’s IP address.

Instead, DNS is hierarchical.

Each layer delegates responsibility.

Think:
```
Root
 ↓
Who handles .com?
 ↓
.com
 ↓
Who handles cresignsys.com?
 ↓
Authoritative server
 ↓
What is templates?
 ↓
A/AAAA answer
```
38. Delegation

This is a fundamental DNS concept.

A parent zone delegates authority to nameservers responsible for a child zone.

Conceptually:
```
.com
 ↓
delegates cresignsys.com
 ↓
cresignsys.com nameservers
```
39. Nameserver Configuration

At the domain-registration level, you normally specify nameservers.

For example:
```
ns1.provider.example
ns2.provider.example
```
This tells the DNS hierarchy where the authoritative DNS service for the domain can be found.

40. The DNS Zone

Once the authoritative nameserver is identified, it can answer questions such as:
```
What is the A record?
What is the AAAA record?
What are the MX records?
What are the TXT records?
```
41. Example Zone

A simplified conceptual zone might be:
```
cresignsys.com.       A       203.0.113.50

www                   CNAME   cresignsys.com.

templates             A       203.0.113.50

learn                 A       203.0.113.50

shop                  A       203.0.113.50

cresignsys.com.       MX      mail.example.com.
```
The exact records on your real domain may be different.

42. Multiple Websites on One IP

This is extremely important for your hosting platform.

You can have:
```
templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com
```
all pointing to:
```
same public IP
```
For example:
```
templates → 203.0.113.50
learn     → 203.0.113.50
shop      → 203.0.113.50
```
DNS doesn’t need a separate IP for every website.

43. How Does Nginx Know Which Website?

This is where DNS ends and HTTP/Nginx begins.

The browser connects to:
```
203.0.113.50:443
```
but sends information identifying the requested hostname through TLS/HTTP mechanisms.

Nginx can then choose the appropriate:
```
server block
```
for:
```
templates.cresignsys.com
```
or:
```
shop.cresignsys.com
```
44. One IP, Many Domains

Conceptually:
```
                    Public IP
                 203.0.113.50
                       │
              ┌────────┼────────┐
              ▼        ▼        ▼
          templates   learn    shop
              │        │        │
              ▼        ▼        ▼
           Nginx server blocks
```
This is a fundamental reason modern hosting can put many websites on one server/IP.

45. DNS Does Not Select the Website

DNS only gets you to the IP.

Then the web server uses the hostname/request information to determine the website.

So:
```
DNS
 ↓
IP
```
then:
```
HTTP/TLS
 ↓
hostname
 ↓
Nginx server block
```
46. SNI

For HTTPS, the hostname is typically communicated during the TLS handshake using:

SNI — Server Name Indication

Conceptually:
```
Client
 ↓
TLS ClientHello
 ↓
SNI = templates.cresignsys.com
 ↓
Nginx
```
This allows the server to select the appropriate certificate for the hostname.

47. Why SNI Was Important

Suppose one IP hosts:
```
site1.com
site2.com
site3.com
```
Each may have a different certificate.

SNI allows the client to tell the server which hostname it wants during the TLS handshake.

Conceptually:
```
203.0.113.50:443
       │
       ├── site1.com
       ├── site2.com
       └── site3.com
```
48. DNS + SNI + Nginx

This is a critical hosting relationship:
```
DNS
 ↓
IP address

SNI
 ↓
requested hostname

Nginx
 ↓
correct certificate/server block
```
49. DNS + Nginx Configuration

Suppose DNS has:
```
templates.cresignsys.com
        ↓
YOUR_PUBLIC_IP
```
Nginx might have:
```
server {
    server_name templates.cresignsys.com;

    root /storage/websites/templates.cresignsys.com/public;
}
```
Now the pieces connect.

50. Complete Flow for Your Domain

When a user enters:
```
https://templates.cresignsys.com
```
the simplified sequence is:
```
1. Browser checks local DNS cache
             ↓
2. Resolver lookup
             ↓
3. Authoritative DNS
             ↓
4. A/AAAA answer
             ↓
5. Browser obtains IP
             ↓
6. TCP connection to :443
             ↓
7. TLS handshake
             ↓
8. SNI = templates.cresignsys.com
             ↓
9. Nginx selects certificate/server block
             ↓
10. HTTP request
             ↓
11. WordPress if required
```
51. Local DNS Cache

The browser or operating system may already know the answer.

So the browser might not perform a new DNS query every time.

Conceptually:
```
Browser cache
   ↓
OS cache
   ↓
local resolver
   ↓
recursive resolver
```
The exact caching layers vary.

52. dig

You can inspect DNS directly.

Run:
```
dig templates.cresignsys.com
```
You may see an answer section containing an A record.

53. Query Only A
```
dig A templates.cresignsys.com
```
This asks specifically for IPv4.

54. Query AAAA
```
dig AAAA templates.cresignsys.com
```
This asks for IPv6.

55. Query CNAME
```
dig CNAME templates.cresignsys.com
```
This checks whether the name is a CNAME.

56. Query NS
```
dig NS cresignsys.com
```
This shows nameserver information.

57. Query MX
```
dig MX cresignsys.com
```
This checks mail exchange records.

58. Query TXT
```
dig TXT cresignsys.com
```
This can show TXT records used for verification and email-related policies.

59. +short

For concise results:
```
dig +short A templates.cresignsys.com
```
This is very useful in server scripts.

60. Trace DNS

You can ask dig to trace the DNS delegation process:
```
dig +trace templates.cresignsys.com
```
Conceptually, this allows you to observe the hierarchy:
```
Root
 ↓
.com
 ↓
cresignsys.com
 ↓
templates.cresignsys.com
```
61. Why +trace Is Educational

It makes the hierarchy visible.

You can actually see that DNS isn’t:
```
one giant database
```
Instead, it is:
```
distributed
hierarchical
delegated
cached
```
62. DNS Uses UDP and TCP

Traditional DNS commonly uses:
```
UDP 53
```
but DNS can also use:
```
TCP 53
```
under certain circumstances.

Modern DNS-related technologies can also use other transports, such as DNS over HTTPS or DNS over TLS, which we will study later.

63. Why UDP?

Traditional DNS queries are often small and benefit from low overhead.

Conceptually:
```
DNS query
 ↓
UDP
 ↓
DNS response
```
But DNS is not limited to UDP.

64. DNS Over HTTPS

There is also:

DoH

DNS over HTTPS.

Conceptually:
```
Browser
 ↓
HTTPS
 ↓
DNS resolver
```
This encrypts DNS queries between the client and the DoH resolver.

65. DNS Over TLS

There is also:

DoT

DNS over TLS.

Conceptually:
```
Client
 ↓
TLS
 ↓
DNS resolver
```
Both DoH and DoT protect DNS traffic between the client and resolver, but they use different transport/application mechanisms.

66. Traditional DNS vs DoH/DoT

Traditional:
```
Client
 ↓
DNS
 ↓
Resolver
```
DoT:
```
Client
 ↓
TLS
 ↓
DNS
 ↓
Resolver
```
DoH:
```
Client
 ↓
HTTPS
 ↓
DNS
 ↓
Resolver
```
67. DNS Security vs HTTPS Security

Don’t confuse:
```
DNS security
```
with:
```
website TLS
```
For example:
```
DNS lookup
```
can be protected with DoH/DoT, while:
```
https://templates.cresignsys.com
```
uses TLS to protect the actual web session.

They are separate layers.

68. DNSSEC

Another important technology is:

DNSSEC

DNSSEC adds cryptographic authentication to DNS data.

Its purpose is to help detect forged/manipulated DNS responses.

Conceptually:
```
DNS data
 ↓
cryptographic signatures
 ↓
resolver validation
```
69. DNSSEC Does Not Encrypt DNS

This is important.

DNSSEC primarily provides:
```
Authenticity
Integrity
```
It does not make ordinary DNS queries confidential.

So:
```
DNSSEC
≠
DNS encryption
```
DoH/DoT address confidentiality between client and resolver.

70. DNSSEC Chain of Trust

DNSSEC uses a hierarchical chain of trust.

Conceptually:
```
Root trust
   ↓
TLD
   ↓
Domain
   ↓
DNS record
```
This mirrors the hierarchical nature of DNS itself.

71. DNS and Let’s Encrypt

Now connect DNS to your SSL lesson.

Let’s Encrypt needs to verify control of a domain before issuing a certificate.

One validation method is:

DNS-01

The certificate authority asks you to create a specific DNS record.

Conceptually:
```
Let's Encrypt
      ↓
DNS challenge
      ↓
TXT record
      ↓
Authoritative DNS
      ↓
validation
```
72. HTTP-01

Another common validation method is:

HTTP-01

Let’s Encrypt checks a special URL over HTTP.

Conceptually:
```
Let's Encrypt
      ↓
http://domain/.well-known/acme-challenge/...
      ↓
Your web server
      ↓
challenge response
```
This is one reason port 80 can be useful even when your site ultimately uses HTTPS.

73. Your SSL Installation

Earlier you received:
```
Successfully received certificate.
```
Behind the scenes, the process involved:
```
Certbot
 ↓
Let's Encrypt
 ↓
Domain validation
 ↓
Certificate issuance
 ↓
Certificate installation
 ↓
Nginx
```
DNS is part of the larger domain-validation infrastructure, though the exact challenge type depends on the Certbot configuration.

74. DNS Is a Dependency of Hosting

Your website can have:
```
Perfect Nginx
Perfect WordPress
Perfect SSL
```
but if:
```
DNS
 ↓
wrong IP
```
users still won’t reach the correct server.

75. DNS Failure Example

Suppose:
```
templates.cresignsys.com
```
points to:
```
Old VPS
```
while your website is on:
```
New VPS
```
Then:
```
Browser
 ↓
DNS
 ↓
Old VPS
```
Your new Nginx server may be completely healthy but invisible to those users.

76. DNS Record Change

Suppose:
```
Before:

templates → 203.0.113.50
```
Then:
```
After:

templates → 203.0.113.80
```
Users with cached answers may continue reaching the old IP until their cached data expires or is refreshed.

77. DNS Is Distributed

This is one of the deepest concepts.

There isn’t one server where everyone asks:
```
"What is templates.cresignsys.com?"
```
Instead:
```
Browser
 ↓
Resolver
 ↓
Cache / hierarchy
 ↓
Authoritative server
```
Different users may use different recursive resolvers.

78. The DNS Hierarchy

Memorize this:
```
                    ROOT
                      │
                      ▼
                    .COM
                      │
                      ▼
               cresignsys.com
                      │
                      ▼
          templates.cresignsys.com
```
The actual lookup involves delegation and authoritative data.

79. DNS Is Data, Not Traffic Routing

Another important distinction:

DNS says:
```
"Use this address/name."
```
It doesn’t carry your website’s HTTP content.

The actual website traffic comes later:
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
```
80. Complete Technology Chain

You now know:
```
DOMAIN
  ↓
DNS
  ↓
IP
  ↓
ROUTING
  ↓
VNIC
  ↓
FIREWALL
  ↓
TCP
  ↓
TLS
  ↓
HTTP
  ↓
NGINX
  ↓
PHP-FPM
  ↓
WORDPRESS
  ↓
MYSQL
  ↓
FILESYSTEM
  ↓
STORAGE
```
This is the backbone of modern web hosting.

81. Your templates.cresignsys.com

The complete conceptual journey is:
```
templates.cresignsys.com
          │
          ▼
     DNS A/AAAA
          │
          ▼
     Public IP
          │
          ▼
    Oracle Cloud VCN
          │
          ▼
        VNIC
          │
          ▼
     Ubuntu network
          │
          ▼
       TCP :443
          │
          ▼
       TLS/SNI
          │
          ▼
        Nginx
          │
          ▼
server_name templates.cresignsys.com
          │
          ▼
root /storage/websites/templates.cresignsys.com/public
          │
          ▼
       WordPress
```
82. Practical DNS Investigation

For your actual domain, these commands are worth learning:
```
dig A templates.cresignsys.com
```
```
dig AAAA templates.cresignsys.com
```
```
dig NS cresignsys.com
```
```
dig MX cresignsys.com
```
```
dig TXT cresignsys.com
```
```
dig +trace templates.cresignsys.com
```
And:
```
curl -v https://templates.cresignsys.com
```
83. The Most Important Concepts

Memorize:
```
Domain
=
human-friendly hierarchical name

DNS
=
distributed naming system

A
=
IPv4 address

AAAA
=
IPv6 address

CNAME
=
alias to another DNS name

MX
=
mail server information

TXT
=
text/verification/policy data

NS
=
authoritative nameserver delegation

TTL
=
cache lifetime

Resolver
=
finds DNS answers for clients

Authoritative server
=
source of authoritative zone data
```
84. The Key Difference

Don’t mix these three:
```
DNS
 ↓
Where is the server?

TCP
 ↓
Can I establish a reliable connection?

TLS
 ↓
Can I securely communicate with/authenticate the server?
```
Then:
```
HTTP
 ↓
What web resource do I want?
```
Lesson 036 Summary

When a user enters:
```
https://templates.cresignsys.com
```
the first major operation is:
```
templates.cresignsys.com
        ↓
DNS
        ↓
IP address
```
Then:
```
IP
 ↓
routing
 ↓
VNIC
 ↓
firewall
 ↓
TCP :443
 ↓
TLS
 ↓
SNI
 ↓
Nginx
 ↓
HTTP
```
That is the beginning-to-end relationship between DNS, networking, TLS and web hosting.

Next Lesson — 037

TCP — The Deepest Basics

We will go below DNS and study what happens after the IP address is known:
```
IP address
 ↓
TCP
 ↓
Port
 ↓
Socket
 ↓
SYN
 ↓
SYN-ACK
 ↓
ACK
 ↓
Sequence numbers
 ↓
Acknowledgements
 ↓
Retransmission
 ↓
Flow control
 ↓
Congestion control
 ↓
Connection termination
```
Then we will trace a real HTTPS connection:
```
Browser
     ↓
TCP SYN
     ↓
Oracle Cloud
     ↓
Ubuntu
     ↓
Nginx :443
     ↓
TCP connection
     ↓
TLS handshake
```
This will form the foundation for understanding why websites sometimes show connection timeout, connection refused, reset, 502, 503, or 504 errors.
August 13, 2026
CresignSys Learn — Lesson 035
Linux Networking — From Internet to Your Nginx Process

We now move from the filesystem into networking inside the VPS.

The central question is:

When someone opens https://templates.cresignsys.com, how does the network packet travel from their computer all the way to the Nginx process running inside your Ubuntu server?

1. Start With the Complete Journey

At a high level:
```
Browser
   ↓
DNS
   ↓
Internet
   ↓
Cloud network
   ↓
Public IP
   ↓
VNIC
   ↓
Subnet
   ↓
Firewall/security rules
   ↓
Ubuntu network stack
   ↓
TCP :443
   ↓
Nginx
   ↓
TLS
   ↓
HTTP
```
There are many layers hidden inside this simple diagram.

We will open them one by one.

2. What Is a Network?

A network is a system that allows devices to exchange data.

For example:
```
Computer A
     │
     │
   Network
     │
     │
Computer B
```
Your VPS is simply another network-connected computer.

3. The Internet

The Internet is not one giant physical cable controlled by one machine.

It is a:

Network of networks

Conceptually:
```
Your PC
   ↓
Home/Office Network
   ↓
ISP
   ↓
Internet
   ↓
Cloud Provider
   ↓
Your VPS
```
Different networks communicate using standardized protocols.

4. Network Interface

Your Ubuntu server needs a network interface to communicate with a network.

Run:
```
ip addr
```
You may see something similar to:
```
lo
eth0
```
or:
```
lo
ens3
```
The exact name depends on the operating system and cloud environment.

5. lo

The interface:
```
lo
```
means:

Loopback

Its typical IPv4 address is:
```
127.0.0.1
```
This means:

This computer itself.

6. Loopback Example

Suppose Nginx communicates with another service locally.

Conceptually:
```
Nginx
 ↓
127.0.0.1
 ↓
local service
```
The packet does not need to travel out to the Internet.

7. Network Interface and IP Address

An interface can have one or more IP addresses.

For example:
```
eth0
 ├── IPv4 address
 └── IPv6 address
```
The actual addresses on your Oracle Cloud VM depend on your VNIC configuration.

8. What Is an IP Address?

An IP address identifies a network endpoint/address.

Example IPv4:
```
192.168.1.10
```
Another:
```
10.0.0.5
```
A public IPv4 might look like:
```
203.0.113.50
```
The last example uses a documentation range.

9. IPv4

IPv4 addresses are:
```
32 bits
```
Usually written as four decimal numbers:
```
192.168.1.10
```
Each section represents 8 bits:
```
192 . 168 . 1 . 10
 ↓     ↓    ↓    ↓
 8     8    8    8 bits
```
Total:
```
8 × 4 = 32 bits
```
10. IPv6

IPv6 uses:
```
128 bits
```
Example:
```
2001:db8::1
```
IPv6 was developed primarily because IPv4 has a limited address space.

11. Public IP vs Private IP

This is fundamental for cloud hosting.

Private IP

Used within private/internal networks.

Common IPv4 private ranges include:
```
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
```
Public IP

Routable through the public Internet.

Your Oracle Cloud networking configuration determines how your VM is reached publicly.

12. Your Oracle Cloud VPS

Conceptually, your architecture is something like:
```
Internet
   ↓
Public IP
   ↓
Oracle Cloud VCN
   ↓
Subnet
   ↓
VNIC
   ↓
Private IP
   ↓
Ubuntu
```
The exact OCI implementation involves additional virtual networking components.

13. VCN

Oracle Cloud uses:

VCN — Virtual Cloud Network

Think of it as your private virtual network inside Oracle Cloud.

Conceptually:
```
Oracle Cloud
└── VCN
    ├── Subnet
    │   ├── VM 1
    │   ├── VM 2
    │   └── VM 3
    └── ...
```
14. Subnet

A subnet divides a network into a smaller network segment.

For example:
```
VCN
   ↓
Subnet
   ↓
VM
```
The subnet has an IP address range.

Example:
```
10.0.0.0/24
```
This is an example only; your actual OCI subnet may be different.

15. CIDR

You will frequently encounter notation such as:
```
10.0.0.0/24
```
This is:

CIDR notation

The /24 indicates that the first 24 bits represent the network prefix.

16. /24

IPv4 has:
```
32 bits
```
Therefore:
```
/24
```
means:
```
24 network bits
8 remaining host bits
```
So the range contains:
```
2^8 = 256
```
IPv4 addresses in the mathematical range.

Some addresses may have special/reserved purposes depending on the network context.

17. Example Subnet

Imagine:
```
10.0.1.0/24
```
Conceptually:
```
Network:
10.0.1.0

Possible addresses:
10.0.1.x
```
The exact usable-address rules depend on the networking environment.

18. Why Subnets Matter

The server needs to know:

Is this destination on my local network or somewhere else?

The subnet/routing configuration helps determine that.

19. Routing

Suppose your server wants to communicate with:
```
8.8.8.8
```
Linux asks:

Where should I send this packet?

The answer comes from the:

Routing table

Run:
```
ip route
```
20. Example Routing Table

You might see something conceptually like:
```
default via 10.0.0.1 dev eth0
10.0.0.0/24 dev eth0
```
Meaning approximately:
```
10.0.0.0/24
 ↓
directly reachable through eth0

everything else
 ↓
default gateway
```
Your actual output will differ.

21. Default Gateway

The:

Default gateway

is the next-hop router used for destinations that don’t have a more specific route.

Conceptually:
```
Server
  ↓
Default gateway
  ↓
Other network
  ↓
Internet
```
22. Local vs Remote Destination

Suppose:
```
Server:
10.0.1.20

Destination:
10.0.1.50
```
If the routing configuration considers it directly connected:
```
Server
 ↓
local network
 ↓
10.0.1.50
```
But:
```
Server:
10.0.1.20

Destination:
8.8.8.8
```
may use:
```
Server
 ↓
default gateway
 ↓
Internet
```
23. MAC Address

IP is not the only addressing system.

Network interfaces also have:

MAC addresses

Example:
```
02:42:ac:11:00:02
```
A MAC address identifies a network interface at the local link layer.

The exact semantics in cloud virtual networking can be more abstract than physical Ethernet.

24. IP vs MAC

Simplified:
```
MAC
=
local network/link addressing

IP
=
network-layer addressing
```
Think:
```
IP
 ↓
Where is the destination network/device?

MAC
 ↓
Which local network interface should receive this frame?
```
25. ARP

For IPv4 local-network communication, systems traditionally use:

ARP — Address Resolution Protocol

to determine a link-layer address associated with an IPv4 address.

Conceptually:
```
IP address
   ↓
ARP
   ↓
MAC address
```
In cloud networks, the underlying implementation may involve virtualized networking mechanisms.

26. IPv6 Uses Neighbor Discovery

IPv6 doesn’t use ARP.

It uses:

Neighbor Discovery Protocol

which is built using ICMPv6.

Conceptually:
```
IPv6
 ↓
Neighbor Discovery
 ↓
Link-layer information
```
27. Packet

Data sent over a network is divided into units.

At the IP layer, we commonly talk about:

Packets

Conceptually:
```
Large data
 ↓
smaller packets
 ↓
network
```
Each packet contains addressing/control information and payload.

28. Packet Structure

At a simplified level:
```
┌───────────────────────────┐
│ IP header                 │
├───────────────────────────┤
│ TCP/UDP header            │
├───────────────────────────┤
│ Application data         │
└───────────────────────────┘
```
The exact encapsulation is more detailed.

29. Protocol Layers

A very useful mental model:
```
Application
     ↓
Transport
     ↓
Internet
     ↓
Link
```
Examples:
```
Application → HTTP / DNS / TLS
Transport   → TCP / UDP
Internet    → IP
Link        → Ethernet / virtual link
```
30. TCP

TCP is:

Transmission Control Protocol

It provides reliable, ordered byte-stream communication.

For HTTPS:
```
Browser
 ↓
TCP
 ↓
Server
```
TCP establishes a connection before application data is exchanged.

31. UDP

UDP is:

User Datagram Protocol

It provides a connectionless datagram transport with much less built-in reliability than TCP.

Examples of protocols/applications that can use UDP include:
```
DNS
QUIC
some streaming/real-time applications
```
32. TCP Port

A TCP port identifies an application/service endpoint on a host.

Examples:
```
22  → SSH
80  → HTTP
443 → HTTPS
3306 → MySQL commonly
```
Port numbers are part of TCP/UDP transport addressing.

33. IP + Port

A connection endpoint can conceptually be represented as:
```
IP address + port
```
Example:
```
203.0.113.50:443
```
This means:
```
IP:
203.0.113.50

Port:
443
```
34. Socket

A socket is an operating-system abstraction for network communication.

Conceptually:
```
Application
 ↓
Socket
 ↓
TCP/UDP
 ↓
IP
```
Nginx uses sockets to communicate with clients.

35. Nginx Listening on 443

When you have HTTPS working, Nginx is typically listening on:
```
TCP 443
```
Check:
```
sudo ss -lntp
```
You may see something like:
```
LISTEN
0.0.0.0:443
```
36. 0.0.0.0

When a service listens on:
```
0.0.0.0:443
```
it means, conceptually:

Listen on port 443 on all IPv4 local interfaces.

It does not mean that 0.0.0.0 itself is a remote destination.

37. 127.0.0.1

Compare:
```
127.0.0.1:443
```
This means the service is bound only to the local loopback interface.

External clients normally cannot directly reach it through the server’s external interface.

38. [::]:443

You may see:
```
[::]:443
```
This represents an IPv6 wildcard listener.

Whether it also accepts IPv4 connections depends on the operating system/socket configuration.

39. The Firewall

Now we reach a critical layer.

A packet can arrive at the cloud network, but still be blocked before Nginx sees it.

You may have multiple filtering layers:
```
Internet
 ↓
OCI network security rules
 ↓
Ubuntu firewall
 ↓
Nginx
```
40. Cloud Firewall

Oracle Cloud provides network security controls such as:
```
Security Lists
Network Security Groups
```
These can control traffic to/from VNICs.

The exact configuration depends on your OCI setup.

41. Ubuntu Firewall

Ubuntu may use:

UFW

as a user-friendly firewall interface.

Check:
```
sudo ufw status
```
If enabled, it can control local host traffic.

42. Firewall Rule

A simplified firewall rule might say:
```
Allow
TCP
443
from Internet
```
or:
```
Deny
TCP
3306
from Internet
```
43. Why MySQL Should Usually Be Protected

Your architecture should generally be:
```
Internet
   ↓
443
   ↓
Nginx
   ↓
PHP
   ↓
MySQL
```
rather than:
```
Internet
   ↓
3306
   ↓
MySQL
```
unless you have a specific need for remote database access and have secured it appropriately.

44. Port 80

HTTP traditionally uses:
```
TCP 80
```
HTTPS traditionally uses:
```
TCP 443
```
Your Nginx server may listen on both.

45. Why Keep Port 80?

Common reasons include:
```
HTTP → HTTPS redirect
```
and:
```
Let's Encrypt HTTP-01 validation
```
depending on your certificate configuration.

46. Port 443

Port 443 carries:
```
TLS
```
which protects application traffic such as HTTPS.

So:
```
TCP 443
 ↓
TLS
 ↓
HTTP
```
47. TCP Connection Establishment

Before ordinary HTTPS data is exchanged over TCP, TCP normally performs its connection-establishment handshake.

The simplified sequence is:
```
Client                    Server

SYN       ───────────────►
          ◄──────── SYN-ACK
ACK       ───────────────►
```
Then the TCP connection is established.

48. SYN

SYN is a TCP control flag used to initiate a connection.

Conceptually:
```
Client
 ↓
SYN
 ↓
Server
```
49. SYN-ACK

Server responds:
```
SYN + ACK
```
meaning roughly:

I received your request and I’m acknowledging it while synchronizing my sequence state.

50. ACK

Client sends:
```
ACK
```
The TCP connection is now established.

Then TLS can proceed for HTTPS.

51. TCP vs TLS

This distinction is extremely important.

TCP provides:
```
Reliable ordered byte stream
```
TLS provides:
```
Encryption
Authentication
Integrity protection
```
So:
```
HTTPS
=
HTTP
over TLS
over TCP
over IP
```
for traditional HTTPS over TCP.

52. HTTPS Request Stack

A simplified stack:
```
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Link/network
```
This is one of the most important diagrams in web hosting.

53. DNS Comes Before This

When the browser sees:
```
templates.cresignsys.com
```
it needs to determine which IP address corresponds to the domain.

So:
```
Domain
 ↓
DNS
 ↓
IP address
```
Then networking begins toward that IP.

54. Complete HTTPS Journey

Now combine everything:
```
User Browser
      │
      ▼
templates.cresignsys.com
      │
      ▼
DNS
      │
      ▼
Public IP
      │
      ▼
Internet routing
      │
      ▼
Oracle Cloud
      │
      ▼
VCN
      │
      ▼
Subnet
      │
      ▼
VNIC
      │
      ▼
Security rules
      │
      ▼
Ubuntu
      │
      ▼
TCP :443
      │
      ▼
Nginx
      │
      ▼
TLS
      │
      ▼
HTTP
```
55. But There Is More

The packet does not simply travel:
```
Browser → VPS
```
There can be many routers between them.

Conceptually:
```
Browser
 ↓
Router
 ↓
ISP
 ↓
ISP backbone
 ↓
Internet exchange/transit
 ↓
Cloud provider network
 ↓
Oracle network
 ↓
VPS
```
The exact route changes over time.

56. traceroute

You can investigate routing paths with:
```
traceroute example.com
```
On some systems you may need to install it.

Another common tool:
```
tracepath example.com
```
The result shows network hops as observed from your system.

Not every hop will respond because routers may filter diagnostic traffic.

57. ping

Try:
```
ping example.com
```
Ping uses ICMP, not TCP.

Therefore:

A failed ping does not necessarily mean the website is down.

A firewall may simply block ICMP.

58. curl

For web testing, curl is much more relevant.

For example:
```
curl -I https://templates.cresignsys.com
```
This sends an HTTP request and displays response headers.

59. curl and TLS

You can also use:
```
curl -v https://templates.cresignsys.com
```
This can show details such as:
```
DNS resolution
TCP connection
TLS handshake
certificate
HTTP request
HTTP response
```
This is an excellent learning tool.

60. ss

On your server:
```
sudo ss -lntp
```
helps answer:

Which processes are listening on TCP ports?

You may find:
```
:22
:80
:443
```
and perhaps internal services.

61. Listening vs Established

ss can show:
```
LISTEN
```
and:
```
ESTAB
```
LISTEN

Waiting for incoming connections.

ESTAB

An established connection exists.

62. Example

Conceptually:
```
LISTEN
0.0.0.0:443
nginx
```
means:
```
Nginx
 ↓
waiting for HTTPS connections
```
An established connection might look conceptually like:
```
ESTAB
client-ip:random-port
server-ip:443
```
63. Ephemeral Ports

A client generally doesn’t use port 443 as its source port.

Instead it gets a temporary:

Ephemeral port

For example:
```
Client:
192.168.1.20:53142

Server:
203.0.113.50:443
```
The connection is identified by multiple pieces of information.

64. The TCP 4-Tuple

A TCP connection is commonly identified by:
```
Source IP
Source port
Destination IP
Destination port
```
For example:
```
192.168.1.20
53142
203.0.113.50
443
```
This allows many simultaneous clients to connect to the same server port.

65. How 10,000 Users Can Use Port 443

You might wonder:

If Nginx only listens on port 443, how can thousands of users connect?

Because each connection has different source information.

For example:
```
Client A: 10.0.0.10:50001 → Server:443
Client B: 10.0.0.11:50002 → Server:443
Client C: 10.0.0.12:50003 → Server:443
```
The server can distinguish the connections.

66. NAT

NAT means:

Network Address Translation

It allows addresses to be translated between networks.

For example, a home network might use:
```
192.168.1.x
```
internally while sharing one public IPv4 address.

Cloud networking can also involve address translation depending on the architecture.

67. Your Browser Doesn’t Know Your VPS’s Private IP

A public website generally exposes a public-facing address.

The cloud networking layer may translate or route traffic to the VM’s private address/interface.

Conceptually:
```
Public IP
   ↓
Cloud networking
   ↓
Private IP/VNIC
   ↓
VM
```
The exact OCI public/private IP implementation depends on the resource configuration.

68. VNIC

Your Oracle Cloud VM has a:

Virtual Network Interface Card

or:

VNIC

Conceptually:
```
VM
 │
 └── VNIC
      ├── Private IP
      ├── MAC address
      └── network connectivity
```
The VNIC connects the VM to the VCN/subnet.

69. The Cloud Network Is Virtual

There may not be a physical Ethernet cable directly connected to your VPS.

Instead:
```
Physical infrastructure
       ↓
Virtualization
       ↓
Virtual network
       ↓
VNIC
       ↓
VM
```
The cloud provider manages the underlying hardware and virtualization.

70. Packet Arrives at the VM

Eventually the packet reaches the VM’s virtual network interface.

Then:
```
VNIC
 ↓
Linux network driver
 ↓
Linux networking stack
 ↓
TCP
 ↓
socket
 ↓
Nginx
```
This is the critical internal journey.

71. Linux Network Stack

Inside Ubuntu:
```
Network interface
       ↓
Network driver
       ↓
Link layer
       ↓
IP layer
       ↓
TCP layer
       ↓
Socket
       ↓
Nginx
```
This is a simplified representation.

72. Nginx Doesn’t Read Raw Ethernet Directly

Nginx works through operating-system networking abstractions.

Conceptually:
```
Physical/virtual network
 ↓
Linux kernel
 ↓
TCP socket
 ↓
Nginx
```
The kernel handles much of the lower-level networking.

73. Socket Binding

When Nginx starts, it binds/listens on an address and port.

Conceptually:
```
Nginx
 ↓
bind()
 ↓
0.0.0.0:443
 ↓
listen()
```
Then it waits for connections.

74. Accept

When a client connects:
```
Nginx
 ↓
accept()
 ↓
connection socket
```
The listening socket and the individual connection socket are distinct concepts.

75. Two Socket Roles

Conceptually:
```
Listening socket
        │
        ▼
Incoming connection
        │
        ▼
Connection socket
```
Nginx can then process the individual client connection.

76. Nginx Worker

The connection is handled by Nginx’s worker/event architecture.

Conceptually:
```
Listening
   ↓
Connection
   ↓
Worker
   ↓
TLS
   ↓
HTTP
```
77. TLS Begins After TCP

For traditional HTTPS over TCP:
```
TCP handshake
       ↓
TLS handshake
       ↓
HTTP request
```
This ordering is fundamental.

78. TLS Handshake

At a simplified level:
```
Client
   ↓
ClientHello
   ↓
ServerHello
   ↓
Certificate
   ↓
Key exchange
   ↓
Handshake completion
```
The actual TLS 1.3 handshake is more precise and efficient than this simplified sequence.

79. Certificate

Your Let’s Encrypt certificate contains information that allows the browser to authenticate the server’s domain identity through the certificate chain and validation process.

For:
```
templates.cresignsys.com
```
Nginx uses the certificate and private key configured for that site.

80. Private Key

Your certificate has a corresponding private key.

Conceptually:
```
Certificate
+
Private key
```
The private key must remain secret.

This is why it lives under a protected system path such as:
```
/etc/letsencrypt/
```
rather than the public website directory.

81. Encryption Keys

TLS ultimately establishes symmetric encryption keys for the session.

Conceptually:
```
Handshake
 ↓
key agreement
 ↓
session keys
 ↓
encrypted application data
```
The exact cryptographic details depend on the TLS version and cipher suite.

82. Encrypted HTTP

After TLS is established:
```
HTTP request
 ↓
TLS encryption
 ↓
TCP
 ↓
IP
 ↓
Internet
```
An observer on the network generally cannot read the HTTP contents without the appropriate session keys.

83. Nginx Decrypts TLS

On your server:
```
Encrypted TLS data
       ↓
Nginx TLS implementation
       ↓
Decrypted HTTP request
       ↓
Nginx routing
```
Nginx then decides whether the request is:
```
Static
```
or:
```
PHP/WordPress
```
84. Complete Request

For:
```
https://templates.cresignsys.com/about/
```
the conceptual process is:
```
1. DNS lookup
       ↓
2. TCP connection to :443
       ↓
3. TLS handshake
       ↓
4. HTTP GET /about/
       ↓
5. Nginx receives request
       ↓
6. Nginx checks configuration
       ↓
7. PHP-FPM if necessary
       ↓
8. WordPress
       ↓
9. MySQL
       ↓
10. HTML response
       ↓
11. Nginx
       ↓
12. TLS encryption
       ↓
13. TCP
       ↓
14. Browser
```
85. The Full Hosting Architecture

You can now combine nearly everything learned so far:
```
                         INTERNET
                            │
                            ▼
                           DNS
                            │
                            ▼
                       PUBLIC IP
                            │
                            ▼
                     ORACLE CLOUD VCN
                            │
                         SUBNET
                            │
                           VNIC
                            │
                     SECURITY RULES
                            │
                            ▼
                         UBUNTU
                            │
                    ┌───────┴────────┐
                    ▼                ▼
                 Network           Kernel
                    │                │
                    ▼                ▼
                  TCP             Processes
                    │                │
                    ▼        ┌───────┼────────┐
                  Socket      ▼       ▼        ▼
                    │       Nginx   PHP-FPM  MySQL
                    │         │       │        │
                    └─────────┴───────┴────────┘
                                      │
                                   WordPress
                                      │
                           ┌──────────┴─────────┐
                           ▼                    ▼
                      Filesystem             Database
                           │                    │
                           ▼                    ▼
                      /storage              MySQL data
```
86. Important Commands

Interfaces
```
ip addr
```
Routing
```
ip route
```
Listening ports
```
sudo ss -lntp
```
Connections
```
sudo ss -ntp
```
Firewall
```
sudo ufw status
```
DNS
```
dig templates.cresignsys.com
```
If dig isn’t installed:
```
sudo apt install dnsutils
```
HTTPS
```
curl -v https://templates.cresignsys.com
```
87. A Very Important Diagnostic Sequence

When a website doesn’t open, don’t randomly change configurations.

Think through the layers:
```
1. DNS?
   ↓
2. Public IP?
   ↓
3. Cloud security rule?
   ↓
4. Ubuntu firewall?
   ↓
5. Nginx listening?
   ↓
6. TCP connection?
   ↓
7. TLS certificate/configuration?
   ↓
8. Nginx server block?
   ↓
9. PHP-FPM?
   ↓
10. WordPress?
   ↓
11. MySQL?
```
This layered approach is one of the most valuable server-administration skills.

88. Example: DNS Problem

If:
```
DNS
 ↓
wrong IP
```
then:
```
Browser
 ↓
wrong server
```
Nginx on your VPS may be completely healthy.

89. Example: Port 443 Blocked

Suppose:
```
DNS → correct
Nginx → running
TLS → correct
```
but:
```
OCI security rule
 ↓
TCP 443 blocked
```
Then the browser cannot establish the connection.

90. Example: Nginx Not Listening

Suppose:
```
Cloud firewall → OK
Ubuntu firewall → OK
```
but:
```
Nginx
 ↓
not listening on 443
```
Then the connection can still fail.

Check:
```
sudo ss -lntp
```
91. Example: PHP Problem

Suppose HTTPS works:
```
Browser
 ↓
TLS
 ↓
Nginx
```
but WordPress produces:
```
502 Bad Gateway
```
Then investigate:
```
Nginx
 ↓
PHP-FPM
```
rather than immediately blaming DNS or TLS.

92. Example: Database Problem

Suppose:
```
HTTPS works
Nginx works
PHP works
```
but WordPress says it cannot connect to the database.

Then investigate:
```
PHP
 ↓
MySQL
```
This is why layered troubleshooting is so powerful.

93. The Deepest Concept From This Lesson

A web request is not one operation.

It is a chain:
```
Name resolution
 ↓
Routing
 ↓
Network delivery
 ↓
Firewall
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Web server
 ↓
Application
 ↓
Database
 ↓
Filesystem
```
Every layer has its own job.

Lesson 035 Summary

The most important chain to memorize is:
```
Domain
 ↓
DNS
 ↓
Public IP
 ↓
Internet
 ↓
Cloud VCN
 ↓
Subnet
 ↓
VNIC
 ↓
Security rules
 ↓
Ubuntu
 ↓
Network interface
 ↓
IP
 ↓
TCP
 ↓
Port 443
 ↓
Socket
 ↓
Nginx
 ↓
TLS
 ↓
HTTP
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL / Filesystem
```
Practical commands
```
ip addr
ip route
sudo ss -lntp
sudo ss -ntp
sudo ufw status
dig templates.cresignsys.com
curl -v https://templates.cresignsys.com
```
Next Lesson — 036

DNS — From Domain Name to Your VPS

We will go deeper into:
```
Domain
 ↓
Registrar
 ↓
Nameserver
 ↓
DNS Zone
 ↓
A record
 ↓
AAAA record
 ↓
CNAME
 ↓
MX
 ↓
TXT
 ↓
DNS resolver
 ↓
Recursive lookup
 ↓
Authoritative nameserver
 ↓
TTL
 ↓
Caching
 ↓
Your Oracle Cloud public IP
```
Then we will trace exactly how templates.cresignsys.com becomes the IP address of your VPS before the HTTPS connection even begins.
August 13, 2026
CresignSys Learn — Lesson 034
Linux Filesystem — From / to Your WordPress public/

We now move from memory and processes to storage.

The central question is:

When you type /storage/websites/templates.cresignsys.com/public/, what does that actually mean inside Linux?

1. Storage vs Filesystem

First, separate these two concepts.

Storage

Physical or virtual persistent storage:
```
SSD / NVMe / Cloud Block Volume
```
Filesystem

The structure Linux uses to organize data on that storage:
```
/
├── etc
├── var
├── home
├── storage
└── ...
```
So:
```
Storage
   ↓
Filesystem
   ↓
Directories
   ↓
Files
```
2. Linux Has One Main Directory Tree

Linux does not normally present disks to applications as:
```
C:
D:
E:
```
as Windows commonly does.

Instead, Linux builds a unified hierarchy starting at:
```
/
```
This is called the:

Root directory

3. / Is Not the Same as root

This distinction is important.
```
/
```
means:

Root directory

while:
```
root
```
usually refers to:

The superuser account

So:
```
/
```
and:
```
/root
```
are completely different things.

4. Basic Linux Filesystem

A typical Ubuntu server contains directories such as:
```
/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
├── var
└── ...
```
Your server may also have:
```
/storage
```
if you created or mounted it.

5. Think of / as the Beginning

When you write:
```
/storage
```
Linux interprets it as:
```
/
 ↓
storage
```
When you write:
```
/storage/websites
```
it means:
```
/
 ↓
storage
 ↓
websites
```
6. Your Website Path

Your hosting architecture uses paths such as:
```
/storage/websites/templates.cresignsys.com/public/
```
Break it apart:
```
/
└── storage
    └── websites
        └── templates.cresignsys.com
            └── public
```
7. What Is a Directory?

A directory is a filesystem object that organizes references to files and other directories.

Conceptually:
```
Directory
 ├── file
 ├── file
 └── directory
```
It is better to think of a directory as a namespace/container rather than simply “a folder.”

8. Absolute Path

This is an:

Absolute path
```
/storage/websites/templates.cresignsys.com/public/
```
It starts at:
```
/
```
and therefore doesn’t depend on your current directory.

9. Relative Path

Suppose you’re currently inside:
```
/storage/websites/
```
and run:
```
cd templates.cresignsys.com
```
This is a:

Relative path

It means:
```
current directory
+
templates.cresignsys.com
```
10. Current Directory

Linux remembers your current working directory.

Run:
```
pwd
```
Example:
```
/storage/websites/templates.cresignsys.com/public
```
pwd means:

Print Working Directory

11. cd

Move between directories:
```
cd /storage/websites
```
Then:
```
pwd
```
might show:
```
/storage/websites
```
12. ls

List directory contents:
```
ls
```
More useful:
```
ls -la
```
This shows hidden files and detailed information.

13. .

The symbol:
```
.
```
means:

Current directory

For example:
```
ls .
```
means:

List the current directory.

14. ..

The symbol:
```
..
```
means:

Parent directory

If you are here:
```
/storage/websites/
```
then:
```
cd ..
```
moves to:
```
/storage/
```
15. ~

The symbol:
```
~
```
usually means the current user’s home directory.

For user:
```
ubuntu
```
it might represent:
```
/home/ubuntu
```
16. /root

This is typically the home directory of the root user:
```
/root
```
It is not the filesystem root.

Again:
```
/
    = filesystem root

/root
    = root user's home directory
```
17. /home

Normal user home directories commonly live here:
```
/home/ubuntu
/home/user1
/home/user2
```
18. /etc

This is one of the most important directories for server administration.

It contains configuration.

For example:
```
/etc/nginx/
/etc/ssh/
/etc/mysql/
/etc/php/
```
Your Nginx configuration is under:
```
/etc/nginx/
```
19. /var

/var contains data that changes during system operation.

Important examples:
```
/var/log
/var/lib
/var/cache
```
20. /var/log

Logs are critical when troubleshooting.

For example:
```
/var/log/nginx/
```
may contain Nginx logs.

You may also encounter:
```
/var/log/syslog
```
and other service logs depending on the system.

21. /var/lib

This commonly contains persistent application state.

For example, database software may store data under paths beneath:
```
/var/lib/
```
The exact MySQL/MariaDB path depends on your installation.

22. /run

/run contains runtime state created during boot and service operation.

For example:
```
/run/php/
```
may contain PHP-FPM sockets.

23. /tmp

Temporary files commonly live here.
```
/tmp
```
Applications can use it for temporary data.

You should not assume files there are permanent.

24. /usr

/usr contains a large part of the operating system’s user-space programs, libraries, documentation, and related files.

For example:
```
/usr/bin
/usr/sbin
/usr/lib
```
25. /bin and /sbin

Modern Ubuntu versions use a merged filesystem layout in which directories such as:
```
/bin
/sbin
```
may be symbolic links into:
```
/usr/bin
/usr/sbin
```
So don’t assume these are physically separate storage areas.

26. /dev

/dev provides interfaces to devices.

Examples include:
```
/dev/null
/dev/random
/dev/sda
```
depending on the system.

It is another special filesystem area.

27. /proc

We encountered this in the previous lesson.
```
/proc
```
provides kernel/process information.

Example:
```
cat /proc/meminfo
```
28. /sys
```
/sys
```
provides information and interfaces related to devices, drivers, and the kernel’s device model.

It is another virtual/special filesystem.

29. /dev, /proc, /sys

These are different from ordinary directories containing ordinary files.

Conceptually:
```
/dev
 ↓
Devices

/proc
 ↓
Processes + kernel information

/sys
 ↓
Devices + kernel subsystem information
```
30. /storage

Now we reach your hosting architecture.

You have been using:
```
/storage/websites/
```
This may be:
```
a normal directory
```
or:
```
a mounted filesystem
```
depending on how your VPS storage was configured.

We need to determine which.

31. What Is a Mount?

A filesystem can be attached to a directory called a:

Mount point

Conceptually:
```
Storage device/filesystem
          ↓
      mount point
          ↓
       /storage
```
After mounting, the contents of that filesystem become accessible through:
```
/storage
```
32. Example

Imagine a separate volume:
```
/dev/sdb
```
containing a filesystem.

You can mount it at:
```
/storage
```
Then:
```
/dev/sdb
   ↓
mount
   ↓
/storage
```
Applications access it through the path:
```
/storage/...
```
33. Why Mounts Are Useful for Hosting

Suppose your OS disk contains:
```
/
```
and you have a separate large volume for websites:
```
/storage
```
Then you can keep website data separate from much of the operating system.

Conceptually:
```
OS storage
   ↓
/

Website storage
   ↓
/storage
```
This can simplify capacity management and recovery, depending on the infrastructure.

34. How to Check Mounts

Run:
```
df -h
```
You may see something like:
```
Filesystem      Size  Used Avail Use% Mounted on
/dev/...        ...   ...  ...   ...  /
/dev/...        ...   ...  ...   ...  /storage
```
The exact device names depend on your server.

35. findmnt

A very useful command:
```
findmnt
```
This shows mounted filesystems and their mount points.

For just /storage:
```
findmnt /storage
```
This can tell you whether /storage is a separate mounted filesystem.

36. lsblk

Another important command:
```
lsblk
```
This shows block devices and their relationships.

Conceptually:
```
disk
├── partition
└── partition
```
You may see:
```
nvme0n1
├── nvme0n1p1
└── nvme0n1p2
```
The actual layout varies by cloud image/provider.

37. Block Device

A block device provides storage in blocks.

Examples:
```
/dev/sda
/dev/sdb
/dev/nvme0n1
```
depending on the hardware/virtualization environment.

The filesystem sits on top of the block storage.

38. Storage Stack

A simplified stack is:
```
Application
    ↓
Filesystem
    ↓
Block device
    ↓
Virtual/cloud storage
    ↓
Physical storage infrastructure
```
For example:
```
Nginx
 ↓
ext4 filesystem
 ↓
virtual disk
 ↓
cloud block volume
```
The exact filesystem and device type must be checked on your VPS.

39. Filesystem Types

Common Linux filesystems include:
```
ext4
XFS
Btrfs
```
Your Ubuntu server may commonly use:
```
ext4
```
but don’t assume it.

Check with:
```
df -T
```
or:
```
findmnt -T /storage
```
40. Inode

Now we reach a deeper filesystem concept.

A filesystem doesn’t simply store:
```
filename → data
```
It maintains metadata structures.

One important structure is the:

inode

An inode stores metadata about a filesystem object, such as:
```
File type
Permissions
Owner
Group
Size
Timestamps
References to data blocks
```
The exact details depend on the filesystem.

41. Filename vs Inode

Conceptually:
```
Directory
   │
   ├── index.php ─────→ inode
   │
   └── style.css ─────→ inode
```
The directory associates names with filesystem objects.

The inode contains metadata and references associated with the object.

42. Why Inodes Matter

A filesystem can have:
```
plenty of disk space
```
but still run out of:
```
inodes
```
if it contains enormous numbers of small files.

Then you can encounter problems creating new files even when:
```
df -h
```
shows free space.

43. Check Inode Usage

Run:
```
df -i
```
This displays inode usage.

This is particularly relevant to hosting servers containing:
```
WordPress
cache files
mail
logs
temporary files
many websites
```
44. File Data Blocks

The actual file contents are stored through filesystem data structures that ultimately reference storage blocks.

Conceptually:
```
Filename
   ↓
Directory entry
   ↓
inode
   ↓
data blocks
   ↓
storage
```
This is simplified but gives the right mental model.

45. Why a 1 MB File Isn’t “One Block”

Storage filesystems divide storage into blocks.

For example, a filesystem may use a block size such as:
```
4096 bytes
```
A larger file therefore occupies multiple blocks.

Modern filesystems have many optimizations beyond this simple picture.

46. Your WordPress Directory

Now:
```
/storage/websites/templates.cresignsys.com/public/
```
might contain:
```
index.php
wp-admin/
wp-content/
wp-includes/
wp-config.php
.htaccess
...
```
depending on your installation.

47. WordPress Core

Typical directories:
```
wp-admin/
wp-includes/
wp-content/
```
and core files such as:
```
index.php
wp-load.php
wp-blog-header.php
wp-settings.php
```
48. wp-content

This is particularly important.

It commonly contains:
```
wp-content/
├── plugins/
├── themes/
└── uploads/
```
These are application data/code areas used by WordPress.

49. Plugins

For example:
```
wp-content/plugins/
```
contains plugin directories.

A plugin can contain:
```
PHP
CSS
JavaScript
Images
Other resources
```
50. Themes
```
wp-content/themes/
```
contains installed themes.

Themes may include:
```
PHP
CSS
JavaScript
Images
Fonts
Templates
```
51. Uploads
```
wp-content/uploads/
```
commonly contains uploaded media.

For example:
```
uploads/
├── 2026/
│   ├── 01/
│   ├── 02/
│   └── 08/
```
WordPress organizes media using dates by default, depending on settings.

52. Nginx root

Suppose your Nginx configuration contains:
```
root /storage/websites/templates.cresignsys.com/public;
```
Then Nginx maps URL paths to filesystem paths.

For example:
```
URL:
/logo.png
```
can map conceptually to:
```
/storage/websites/templates.cresignsys.com/public/logo.png
```
53. URL-to-File Mapping

This is fundamental.
```
URL
 ↓
Nginx
 ↓
root
 ↓
filesystem path
```
For example:
```
https://templates.cresignsys.com/css/style.css
```
could map to:
```
/storage/websites/templates.cresignsys.com/public/css/style.css
```
if the file exists and the configuration permits it.

54. But WordPress URLs Are Different

Consider:
```
https://templates.cresignsys.com/about/
```
There may not be a physical:
```
/about/
```
directory.

Instead:
```
/about/
 ↓
Nginx routing
 ↓
index.php
 ↓
WordPress
```
This is why try_files is important.

55. Filesystem vs URL

Don’t confuse:
```
URL path
```
with:
```
filesystem path
```
Example:
```
URL:
/about/

Filesystem:
/storage/websites/templates.cresignsys.com/public/
```
WordPress decides what /about/ means.

56. index.php

A typical WordPress installation has:
```
index.php
```
at the site root.

Nginx may use it as the fallback application entry point.

Conceptually:
```
Unknown URL
    ↓
index.php
    ↓
WordPress
```
57. Filesystem Permissions

Now combine the filesystem with our previous lesson.

Suppose:
```
Nginx/PHP-FPM
        ↓
/storage/websites/...
```
Linux checks:
```
Who is requesting?
        ↓
Which file?
        ↓
Owner/group/permissions
        ↓
Allowed?
```
58. Directory Traversal

Suppose the path is:
```
/storage/websites/site/public/index.php
```
The process needs appropriate permission to traverse the directories:
```
/storage
/storage/websites
/storage/websites/site
/storage/websites/site/public
```
before it can access the file.

This is why permissions on parent directories matter.

59. Ownership Chain

A request might involve:
```
Nginx
 ↓
PHP-FPM
 ↓
www-data
 ↓
filesystem
```
If www-data cannot access a required file:
```
Permission denied
```
can occur.

60. stat

A useful command for examining a file:
```
stat /storage/websites/templates.cresignsys.com/public/index.php
```
It shows metadata such as:
```
File
Size
Blocks
Permissions
UID
GID
Access time
Modify time
Change time
```
61. namei

A very useful command for debugging path permissions:
```
namei -l /storage/websites/templates.cresignsys.com/public/index.php
```
It can show each component of the path and its permissions.

This is extremely useful when diagnosing:
```
Permission denied
```
62. Symbolic Links

Linux supports:

Symbolic links

Example:
```
current
  ↓
/storage/websites/site/releases/2026-08-13
```
A symlink points to another path.

Check with:
```
ls -l
```
You may see:
```
current -> releases/2026-08-13
```
63. Why Symlinks Matter in Hosting

Symlinks can be used for:
```
Deployments
Shared assets
Version switching
Configuration
Certificates
```
They are common in sophisticated deployment systems.

64. Hard Links

Linux filesystems can also have:

Hard links

A hard link is another directory entry referring to the same underlying filesystem object/inode.

Conceptually:
```
name A ──┐
         ├── inode ── data
name B ──┘
```
This is different from a symbolic link.

65. File Deletion

A deeper filesystem concept:

Deleting a filename doesn’t necessarily immediately destroy the underlying data if another hard link still references the inode, or if an open process still holds the file open.

This leads to an important Linux troubleshooting concept.

66. Deleted but Still Open

Suppose:
```
application
 ↓
opens large.log
 ↓
file deleted
```
The directory entry may disappear, but the process can still have the file open.

Disk space can remain occupied until the file descriptor is closed.

Tools such as:
```
lsof
```
can help investigate this.

67. lsof

lsof means:

List Open Files

Linux treats many resources as file descriptors, so lsof can show:
```
Files
Sockets
Deleted-but-open files
```
For example:
```
sudo lsof | head
```
68. Why This Matters for Logs

Suppose an application writes to:
```
/var/log/application.log
```
and the file is deleted while the process still has it open.

You might see:
```
df -h
```
showing unexpectedly high disk usage even though:
```
du
```
doesn’t seem to account for it.

Deleted-but-open files can be one explanation.

69. du

Use:
```
du -sh /storage/websites/*
```
to estimate directory usage.

For a specific site:
```
du -sh /storage/websites/templates.cresignsys.com
```
This is useful for hosting capacity monitoring.

70. df vs du

This distinction is very important.

df

Reports filesystem-level space usage.
```
df -h
```
du

Estimates space consumed by files/directories.
```
du -sh directory
```
They can sometimes disagree for legitimate reasons.

71. Filesystem Mount Boundary

Suppose:
```
/storage
```
is a separate filesystem.

Then:
```
du -sh /
```
may not represent total storage usage across all mounted filesystems in the way you expect.

Always understand your mount structure.

72. Mount Hierarchy

Imagine:
```
/
├── etc
├── var
└── storage
      ↓
    separate filesystem
```
The directory:
```
/storage
```
is a mount point.

The contents of the mounted filesystem appear there.

73. Mounting Hides Underlying Directory Contents

This is a subtle but important concept.

If /storage had files before another filesystem was mounted there:
```
Before:
 /storage
 ├── old-file
 └── old-folder
```
After mounting another filesystem:
```
/storage
 ↓
mounted filesystem
```
the old underlying contents are hidden while the mount is active.

They aren’t necessarily deleted.

74. /etc/fstab

Persistent mounts are often configured through:
```
/etc/fstab
```
This tells Linux how certain filesystems should be mounted.

You can inspect it with:
```
cat /etc/fstab
```
Don’t modify it blindly.

A bad entry can interfere with booting.

75. Mount at Boot

Conceptually:
```
Server boots
 ↓
systemd
 ↓
mount filesystems
 ↓
/storage available
 ↓
hosting services start
```
This matters if your websites depend on a separate storage volume.

76. If /storage Disappears

Imagine Nginx expects:
```
/storage/websites/site/public
```
but the storage filesystem isn’t mounted.

Then the expected files may not be available.

Possible result:
```
Nginx
 ↓
wrong/empty filesystem path
 ↓
website failure
```
The exact behavior depends on what exists underneath the mount point and the configuration.

77. This Is Why Mounts Matter to Hosting

Your hosting architecture may therefore be:
```
Cloud Storage
      ↓
Filesystem
      ↓
/storage
      ↓
/storage/websites
      ↓
domain
      ↓
public
      ↓
WordPress
```
This is a complete storage chain.

78. Website Storage Architecture

A clean conceptual model is:
```
/storage
   │
   └── websites
         │
         ├── site1.com
         │     └── public
         │
         ├── site2.com
         │     └── public
         │
         └── site3.com
               └── public
```
This makes automated hosting easier.

79. Why public/?

The name:
```
public
```
is a convention meaning:

Files intended to be exposed through the web server.

It is not a special Linux directory.

You could technically call it:
```
web
html
htdocs
public_html
site
```
depending on your design.

80. Public vs Private Files

A good web application separates:
```
Public
```
from:
```
Private
```
Conceptually:
```
website
├── public
│   ├── index.php
│   ├── wp-content
│   └── assets
│
└── private
    ├── backups
    ├── secrets
    └── deployment files
```
Only the intended public directory should normally be exposed as the web root.

81. Why This Is a Security Principle

Suppose your website root accidentally exposes:
```
database-backup.sql
.env
private-key
backup.zip
```
An attacker might download sensitive information if the web server serves those files.

Therefore:

Web root should contain only what needs to be web-accessible.

82. Your SSL Files Are Outside the Website

Notice your Let’s Encrypt certificate is stored under:
```
/etc/letsencrypt/
```
not:
```
/storage/websites/templates.cresignsys.com/public/
```
This is intentional.

Private TLS keys should not be publicly downloadable website files.

83. Nginx Configuration Is Also Outside the Website

Your Nginx site configuration is under something like:
```
/etc/nginx/sites-enabled/
```
rather than inside:
```
public/
```
This separates:
```
Application files
```
from:
```
Web-server configuration
```
84. WordPress Configuration

WordPress has:
```
wp-config.php
```
which contains sensitive database configuration.

It must be protected from direct download.

A properly configured PHP/Nginx environment treats .php as executable PHP rather than serving its source code as plain text.

85. Complete Storage-to-Web Chain

Now connect everything:
```
Cloud storage
      ↓
Block device
      ↓
Filesystem
      ↓
Mount
      ↓
/storage
      ↓
/storage/websites
      ↓
/storage/websites/templates.cresignsys.com
      ↓
public
      ↓
WordPress files
      ↓
Nginx root
      ↓
HTTP URL
```
86. URL-to-Storage Example

Browser:
```
https://templates.cresignsys.com/logo.png
```
Nginx:
```
server_name
 ↓
root
```
Filesystem:
```
/storage/websites/templates.cresignsys.com/public/logo.png
```
Then:
```
Storage
 ↓
Linux filesystem
 ↓
Nginx
 ↓
HTTP response
 ↓
TLS
 ↓
Browser
```
87. Dynamic URL Example

Browser:
```
https://templates.cresignsys.com/about/
```
Filesystem may not contain:
```
public/about/index.html
```
Instead:
```
/about/
 ↓
Nginx
 ↓
try_files
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTML
```
So the URL isn’t necessarily a physical file.

88. Static and Dynamic Architecture

You can now see the difference clearly.

Static
```
URL
 ↓
Nginx
 ↓
Filesystem
 ↓
File
 ↓
Response
```
Dynamic
```
URL
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTML
 ↓
Response
```
89. Practical Commands

Run these on your VPS:

Understand /storage
```
findmnt /storage
```
See devices
```
lsblk
```
See filesystem types
```
df -T
```
See disk usage
```
df -h
```
See inode usage
```
df -i
```
See website directory size
```
du -sh /storage/websites/templates.cresignsys.com
```
Inspect website files
```
ls -lah /storage/websites/templates.cresignsys.com/public
```
Inspect file metadata
```
stat /storage/websites/templates.cresignsys.com/public/index.php
```
Inspect every path component
```
namei -l /storage/websites/templates.cresignsys.com/public/index.php
```
90. Do Not Change Anything Yet

For this lesson, use these commands primarily for observation.

Especially avoid experimenting with:
```
mount
umount
chmod -R
chown -R
/etc/fstab
```
until the filesystem and permission model is fully understood.

These can affect your live websites.

91. Deep Mental Model

Your server storage is now:
```
                 CLOUD STORAGE
                       │
                       ▼
                  BLOCK DEVICE
                       │
                       ▼
                   FILESYSTEM
                       │
                       ▼
                    MOUNT
                       │
                       ▼
                   /storage
                       │
                       ▼
                   /websites
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
        Site A       Site B       Site C
          │            │            │
        public       public       public
          │
          ▼
      WordPress
```
And Nginx sits above this:
```
Browser
   ↓
HTTP
   ↓
Nginx
   ↓
root
   ↓
/storage/websites/.../public
```
92. The Most Important Concepts

Memorize:
```
/
= filesystem root

/root
= root user's home

/etc
= configuration

/var
= changing system/application data

/var/log
= logs

/run
= runtime state

/proc
= kernel/process information

/sys
= device/kernel subsystem information

/home
= user home directories

/usr
= system programs/libraries/data

/storage
= your chosen hosting storage location
```
And:
```
Storage
 ↓
Filesystem
 ↓
Mount
 ↓
Directory
 ↓
File
```
93. The Bigger Picture

We have now covered:
```
Hardware
 ↓
Linux Kernel
 ↓
Virtual Memory
 ↓
Processes
 ↓
Filesystem
 ↓
Network
 ↓
Services
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
We are approaching the point where we can understand the VPS as an integrated system rather than isolated technologies.

Lesson 034 Summary

The key idea is:

A path such as /storage/websites/templates.cresignsys.com/public/ is a location in Linux’s unified filesystem namespace. It may ultimately map through a mounted filesystem to cloud storage. Nginx uses that filesystem location as part of serving your website.

The complete relationship:
```
URL
 ↓
Nginx
 ↓
Filesystem path
 ↓
Mount
 ↓
Filesystem
 ↓
Block storage
```
or, for WordPress:
```
URL
 ↓
Nginx
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Filesystem + MySQL
```
Next Lesson — 035

Linux Networking Inside Your VPS

We will go deeper into:
```
Network Interface
 ↓
MAC address
 ↓
IP address
 ↓
Subnet
 ↓
Gateway
 ↓
Routing table
 ↓
ARP / Neighbor Discovery
 ↓
TCP/UDP
 ↓
Port
 ↓
Socket
 ↓
Nginx
```
Then we will connect this directly to your Oracle Cloud VPS:
```
Internet
 ↓
Public IP
 ↓
VNIC
 ↓
Subnet
 ↓
Security List / NSG
 ↓
Ubuntu
 ↓
Nginx :443
```
That will explain exactly how an HTTPS packet from a user’s browser reaches your templates.cresignsys.com Nginx process inside the VPS.
August 13, 2026

Category: Uncategorized

CresignSys Learn — Lesson 043

Linux Filesystem & Permissions — The Foundation of Web Hosting

1. The Hosting Stack So Far

2. Linux Is a Filesystem-Centered System

Root directory

3. / Is Not /root

4. Your Website Path

5. Example

6. Path

7. Absolute Path

8. Relative Path

9. pwd

Print Working Directory

10. ls

11. Example ls -l

12. First Character

13. Permission Characters

14. Read

Read

15. Write

Write

16. Execute

Execute

17. Three Permission Groups

18. Example

19. Numeric Permissions

20. 7

21. 6

22. 5

23. 4

24. 0

25. 755

26. 644

27. Why 644 Is Common for Files

28. Why 755 Is Common for Directories

29. Owner

30. User

31. Group

32. Root

33. sudo

34. Why sudo Matters

35. www-data

36. Why www-data Matters

37. WordPress Needs Write Access

38. Security Principle

39. Why 777 Is Dangerous

40. Principle of Least Privilege

41. Directory Permissions Are Different

42. Example

43. chmod

44. Symbolic Permissions

45. chown

46. chgrp

47. Ownership vs Permissions

48. Example

49. id

50. Check www-data

51. Find Nginx User

52. Find PHP-FPM User

53. Nginx and PHP-FPM May Both Use www-data

54. Website Directory Design

55. Public vs Private

56. Dangerous Files

57. WordPress wp-config.php

58. PHP Source Must Not Be Downloadable

59. Permissions and WordPress

60. Linux File Permissions Are Not the Only Layer

61. ACL

Access Control List

62. getfacl

63. setfacl

64. Symbolic Links

Symbolic link

65. Let’s Encrypt Uses Links

66. Inspect the Links

67. Why live/ Exists

68. Certificate Renewal Connection

69. ls -l Is a Core Skill

70. stat

3. `/` Is Not `/root`

9. `pwd`

10. `ls`

11. Example `ls -l`

20. `7`

21. `6`

22. `5`

23. `4`

24. `0`

25. `755`

26. `644`

33. `sudo`

34. Why `sudo` Matters

35. `www-data`

36. Why `www-data` Matters

39. Why `777` Is Dangerous

43. `chmod`

45. `chown`

46. `chgrp`

49. `id`

50. Check `www-data`

53. Nginx and PHP-FPM May Both Use `www-data`

57. WordPress `wp-config.php`

62. `getfacl`

63. `setfacl`

67. Why `live/` Exists

69. `ls -l` Is a Core Skill

70. `stat`

`ubuntu`

`root`

`www-data`

95. Test Access as `www-data`

98. Why `namei` Is Powerful

8. `server {}`

10. `listen`

12. `server_name`

13. `root`

15. `location`

17. `try_files`

22. What Does `~ \.php$` Mean?