CresignSys Learn

CresignSys Learn — Lesson 049

Written by

cresignsys

in

TLS / HTTPS From the Absolute Basics

We now understand:

Browser
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
???
 ↓
HTTP
 ↓
Nginx

The missing layer is:

TLS

TLS is what makes ordinary HTTP into secure HTTPS.

1. HTTP vs HTTPS

HTTP:

Browser
   ↓
HTTP
   ↓
Server

HTTPS:

Browser
   ↓
TLS
   ↓
HTTP
   ↓
Server

More precisely:

HTTP data
   ↓
TLS protection
   ↓
TCP
   ↓
IP

2. What Does HTTPS Mean?

HTTPS means:

HTTP Secure

It is HTTP transmitted through a secure TLS connection.

So:

HTTPS
=
HTTP
+
TLS

3. Why Do We Need TLS?

Imagine sending:

Username: admin
Password: secret

over an unencrypted connection.

Someone capable of observing the traffic could potentially read the data.

TLS protects the communication against many forms of network interception.

4. TLS Provides Three Major Properties

A useful simplified model is:

TLS
│
├── Confidentiality
├── Integrity
└── Authentication

5. Confidentiality

Confidentiality means:

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

Conceptually:

Browser
   ↓
encrypted data
   ↓
Internet
   ↓
Server

An observer sees encrypted traffic rather than the original HTTP contents.

6. Integrity

Integrity means:

The data should not be silently modified without detection.

For example:

Browser
 ↓
"Pay ₹100"
 ↓
Internet
 ↓
Server

TLS provides mechanisms that allow the receiver to detect tampering with protected records.

7. Authentication

Authentication answers:

Who am I actually communicating with?

When you visit:

https://example.com

the browser needs confidence that the server is authorized for:

example.com

This is where certificates enter.

8. Certificate

A TLS certificate is a digitally signed document containing information about an identity and a public key.

Conceptually:

Certificate
│
├── Domain identity
├── Public key
├── Validity period
├── Issuer
└── Digital signature

9. Example

A certificate might cover:

example.com

and possibly:

www.example.com

depending on the certificate’s Subject Alternative Names.

10. Certificate Is Not the Private Key

This distinction is extremely important.

You have:

Public key
+
Private key

The certificate contains the public key and identity information.

The private key is kept secret on the server.

11. Public Key

A public key can be shared.

Conceptually:

Public key
=
safe to distribute

The browser can receive it as part of the certificate.

12. Private Key

The private key must remain secret.

Conceptually:

Private key
=
server secret

If someone obtains the private key, the security of that certificate’s use can be compromised.

13. Public-Key Cryptography

TLS uses asymmetric cryptographic concepts.

You have:

Public key
        +
Private key

They are mathematically related.

But the private key cannot feasibly be derived from the public key using ordinary practical computation with current cryptographic assumptions.

14. Simple Analogy

Think of:

Public key
=
open padlock

Private key
=
key that controls the padlock

Anyone can have the padlock.

Only the authorized party should have the private key.

This is only an analogy; TLS cryptography is more sophisticated.

15. Certificate Authority

Who says:

This public key belongs to example.com?

A:

Certificate Authority

or:

CA

does this through digital signatures and certificate issuance.

16. Examples of Certificate Authorities

There are many certificate authorities.

One important one for your hosting setup is:

Let’s Encrypt

Let’s Encrypt provides automated, publicly trusted TLS certificates.

17. Trust Chain

Your browser doesn’t blindly trust every certificate.

Instead, it has a set of trusted root certificates.

Conceptually:

Browser
   ↓
Trusted Root CA
   ↓
Intermediate CA
   ↓
Your Website Certificate

This is called a:

Certificate Chain

18. Root CA

A root certificate is trusted by the operating system/browser trust store.

Conceptually:

Root CA
 ↓
trusted

19. Intermediate CA

A root CA often signs an intermediate CA.

Then the intermediate CA issues website certificates.

Conceptually:

Root
 ↓
Intermediate
 ↓
example.com

This allows a hierarchy of trust.

20. Why Not Have the Root Sign Every Website?

Using intermediates provides separation and operational security.

The root can remain more protected while intermediates handle certificate issuance.

21. Certificate Chain

When your server sends the certificate chain:

Server
 ↓
website certificate
 ↓
intermediate certificate

the browser can build a path toward a trusted root.

22. Let’s Encrypt

For your hosting platform, the simplified process is:

Domain
 ↓
prove control
 ↓
Let's Encrypt
 ↓
certificate issued
 ↓
Nginx configured
 ↓
HTTPS

23. Domain Validation

Before issuing a certificate, the CA needs to verify that the requester controls the domain.

One common method is:

HTTP-01 Challenge

The CA asks the server to make a specific resource available.

Conceptually:

Let's Encrypt
 ↓
HTTP request
 ↓
http://example.com/.well-known/...
 ↓
your server

If the expected challenge is returned, domain control is demonstrated.

24. DNS-01 Challenge

Another method is:

DNS-01

The requester proves control by creating a special DNS TXT record.

Conceptually:

Let's Encrypt
 ↓
DNS query
 ↓
TXT record
 ↓
proof of domain control

This is especially useful for some wildcard certificate scenarios.

25. HTTP-01 vs DNS-01

HTTP-01

Domain
 ↓
HTTP
 ↓
challenge file

DNS-01

Domain
 ↓
DNS TXT
 ↓
challenge

26. Wildcard Certificates

Suppose you want:

*.cresignsys.com

This can cover subdomains such as:

learn.cresignsys.com
shop.cresignsys.com
hosting.cresignsys.com

Wildcard certificates generally require DNS-based validation such as DNS-01.

27. One Certificate Per Domain

You can have:

example.com
 ↓
certificate A

and:

shop.example.com
 ↓
certificate B

Or one certificate can cover multiple names through SANs.

28. SAN

SAN means:

Subject Alternative Name

A certificate can contain multiple DNS names.

For example:

example.com
www.example.com
shop.example.com

all could potentially be included in one certificate.

29. Why Your Hosting Platform Needs SSL Automation

Suppose you have:

100 websites

Manually installing certificates would be tedious.

A hosting platform can automate:

Domain created
 ↓
DNS verified
 ↓
Certificate requested
 ↓
Challenge completed
 ↓
Certificate installed
 ↓
Nginx configured
 ↓
HTTPS tested
 ↓
Renewal scheduled

This is exactly the type of workflow a hosting control panel manages.

30. TLS Handshake

Now we reach the deeper part.

Before encrypted application data is exchanged, the client and server perform a:

TLS Handshake

The handshake establishes the parameters needed for the secure connection.

31. Simplified TLS Flow

Conceptually:

Browser
   │
   │ ClientHello
   ▼
Server
   │
   │ ServerHello
   │ Certificate
   ▼
Browser
   │
   │ key establishment
   ▼
Secure keys established
   │
   ▼
Encrypted HTTP

This is a simplified conceptual picture.

Modern TLS 1.3 has a more specific handshake structure.

32. ClientHello

The browser begins with information about what it supports.

Conceptually:

ClientHello
│
├── TLS versions
├── Cipher suites
├── Random value
├── Extensions
└── SNI

33. TLS Version

Modern servers should generally support modern TLS versions.

The major modern version is:

TLS 1.3

TLS 1.2 is also widely deployed.

Old versions such as TLS 1.0 and TLS 1.1 should generally not be enabled on modern public websites.

34. Cipher Suite

A cipher suite describes cryptographic algorithms used by TLS.

You may encounter names such as:

TLS_AES_128_GCM_SHA256

or:

TLS_AES_256_GCM_SHA384

These names look complicated because they describe multiple cryptographic components.

35. Don’t Memorize Cipher Names Yet

At this stage, understand:

Cipher suite
=
set of cryptographic algorithms used by TLS

The important concept is negotiation between client and server.

36. ServerHello

The server selects compatible parameters.

Conceptually:

Client
 ↓
supported options
 ↓
Server
 ↓
chosen options

37. Certificate

The server sends its certificate chain.

For example:

Server
 ↓
example.com certificate
 ↓
intermediate certificate

The browser validates the certificate.

38. Certificate Validation

The browser checks things such as:

Is it expired?
Is the domain name covered?
Is the signature valid?
Is the issuer trusted?
Is the certificate chain valid?

39. Domain Name Validation

Suppose you visit:

https://example.com

but the certificate is only valid for:

otherdomain.com

The browser should reject it or display a certificate warning.

40. Why SNI Exists

Imagine one server has:

example.com
shop.example.com
learn.example.com

all using:

IP address:
203.0.113.25

How does the server know which certificate the client wants?

The browser sends:

SNI

Server Name Indication.

41. SNI

The browser effectively indicates:

I am connecting to:

learn.example.com

during the TLS handshake.

Nginx can then select the appropriate server configuration and certificate.

42. One IP, Many HTTPS Websites

This is fundamental to hosting.

You can have:

203.0.113.25
│
├── example.com
├── shop.example.com
├── learn.example.com
└── anotherdomain.com

All using port:

443

SNI helps the server determine which hostname the client requested.

43. Nginx Server Blocks

You may have configurations like:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate ...;
    ssl_certificate_key ...;
}

and:

server {
    listen 443 ssl;
    server_name shop.example.com;

    ssl_certificate ...;
    ssl_certificate_key ...;
}

Both can listen on:

443

because Nginx uses the hostname and connection information to select the appropriate configuration.

44. Private Key

Nginx needs access to the private key.

Conceptually:

Nginx
 ├── certificate
 └── private key

The private key must have appropriate permissions.

45. Never Publish the Private Key

Do not put:

private key

inside:

public_html
public/
wp-content/

It must remain outside publicly served directories.

46. Public vs Private

For a typical certificate:

Certificate
=
public information
Private key
=
secret

This distinction is critical.

47. Let’s Encrypt Files

Certbot installations commonly use locations under:

/etc/letsencrypt/

For example:

/etc/letsencrypt/live/example.com/

The exact file structure depends on the ACME client and configuration.

48. Common Certificate Files

You may encounter:

fullchain.pem
cert.pem
privkey.pem
chain.pem

Conceptually:

cert.pem
=
website certificate

chain.pem
=
intermediate chain

fullchain.pem
=
certificate + intermediate chain

privkey.pem
=
private key

49. Nginx Configuration

A common Nginx configuration looks conceptually like:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

The exact configuration generated by your certificate tooling can vary.

50. Why fullchain.pem?

The browser needs to be able to build the certificate chain.

Sending the website certificate plus required intermediate certificate(s) helps the client validate the chain.

51. Certificate Expiration

Certificates have a validity period.

Let’s Encrypt certificates are intentionally short-lived.

This is why:

Automatic Renewal

is essential.

52. Why Short-Lived Certificates?

Short-lived certificates reduce the period during which a compromised or otherwise problematic certificate remains valid.

But the trade-off is:

short validity
 ↓
frequent renewal
 ↓
automation required

53. Renewal

Your server needs a process that periodically checks whether certificates need renewal.

For example:

Certificate
 ↓
approaching renewal window
 ↓
ACME client
 ↓
renew
 ↓
update certificate
 ↓
reload Nginx

54. Renewal Failure

If automation fails repeatedly:

certificate expires
 ↓
browser warning
 ↓
website HTTPS problem

This is why SSL monitoring matters in hosting.

55. Test Certificate

You can use:

openssl s_client -connect example.com:443 -servername example.com

This gives detailed TLS information.

56. Why -servername?

This option sends SNI.

For a multi-domain server, that matters.

Without SNI, you may inspect the wrong certificate or default server configuration.

57. curl TLS Testing

You can also use:

curl -Iv https://example.com

This provides useful TLS and HTTP diagnostics.

58. Certificate Inspection

You can inspect a certificate using OpenSSL.

Conceptually:

openssl s_client -connect example.com:443 -servername example.com

Then inspect the certificate chain and TLS negotiation.

59. TLS and HTTP Separation

This is important:

TLS
=
security layer
HTTP
=
application protocol

TLS doesn’t replace HTTP.

It protects HTTP.

60. HTTPS Request

Once TLS is established:

Encrypted connection
        ↓
GET /about/
        ↓
Nginx

The HTTP request is carried inside the TLS-protected connection.

61. What Does an Observer See?

A network observer may be able to see metadata such as:

source IP
destination IP
destination port
traffic timing
traffic size patterns

But properly configured TLS prevents them from simply reading the HTTP request and response contents.

TLS does not make all metadata invisible.

62. HTTPS Does Not Hide the IP Address

Suppose:

example.com
 ↓
203.0.113.25

The network still needs to route traffic to the IP.

So:

HTTPS
≠
anonymous

It primarily protects the contents and authenticates the endpoint through the TLS system.

63. HTTPS Does Not Protect a Compromised Server

Suppose:

WordPress
 ↓
malware

TLS can still be functioning perfectly.

TLS protects communication between client and server.

It does not automatically secure the application itself.

64. HTTPS vs Website Security

These are different:

TLS security

versus:

WordPress security

You need both.

65. TLS Certificate vs Domain Ownership

A certificate doesn’t mean:

The domain belongs to this company in a legal/business sense.

It means the CA validated control of the domain according to the certificate issuance process and issued a certificate.

This distinction matters.

66. Certificate Warning

If the browser says:

Your connection is not private

possible causes include:

expired certificate
wrong hostname
untrusted issuer
incomplete chain
certificate mismatch
incorrect system time
TLS configuration issue

67. Wrong Certificate on Multi-Domain Server

Suppose:

example.com
shop.example.com
learn.example.com

all share one IP.

But the browser receives:

example.com certificate

when visiting:

shop.example.com

Then the hostname doesn’t match.

Possible causes:

incorrect SNI handling
wrong Nginx server block
certificate configuration
default server selection

68. This Is Why server_name Matters

Nginx:

server_name shop.example.com;

tells Nginx which hostname this server block handles.

69. HTTP to HTTPS Redirect

Many websites run:

HTTP :80

and redirect to:

HTTPS :443

Conceptually:

http://example.com
       ↓
301
       ↓
https://example.com

70. Why Keep Port 80?

You might ask:

If HTTPS is secure, why use port 80 at all?

Because HTTP can be used to:

redirect to HTTPS
perform HTTP-01 ACME validation
serve legacy traffic if intentionally configured

Many sites keep port 80 open solely for redirect/validation purposes.

71. Nginx Example

Conceptually:

server {
    listen 80;
    server_name example.com;

    return 301 https://$host$request_uri;
}

Then HTTPS:

server {
    listen 443 ssl;
    server_name example.com;

    ...
}

72. What Happens During a Normal HTTPS Visit?

Let’s trace it.

User types:

https://learn.cresignsys.com

Step 1

DNS:

learn.cresignsys.com
 ↓
IP

Step 2

TCP:

client
 ↓
server:443

Step 3

TCP handshake:

SYN
SYN-ACK
ACK

Step 4

TLS handshake:

ClientHello
ServerHello
Certificate
key establishment

Step 5

Secure session:

encrypted channel

Step 6

HTTP:

GET /
Host: learn.cresignsys.com

Step 7

Nginx:

server_name
 ↓
location
 ↓
WordPress/PHP

73. The Complete Secure Web Stack

You can now visualize:

Browser
   │
   ▼
DNS
   │
   ▼
IP
   │
   ▼
TCP
   │
   ▼
TLS
   │
   ▼
HTTP
   │
   ▼
Nginx
   │
   ▼
PHP-FPM
   │
   ▼
WordPress
   │
   ▼
MySQL

74. Your SSL Automation Architecture

For your CresignSys hosting platform, eventually:

New Domain
    ↓
DNS configured
    ↓
Nginx HTTP server
    ↓
ACME challenge
    ↓
Let's Encrypt
    ↓
Certificate
    ↓
Private key
    ↓
Nginx HTTPS configuration
    ↓
nginx -t
    ↓
reload
    ↓
HTTPS test

Then:

Renewal
 ↓
certificate replacement
 ↓
Nginx reload

75. A Very Important Security Rule

Never do this:

private key
 ↓
public/
 ↓
Internet

Correct:

private key
 ↓
restricted filesystem location
 ↓
Nginx

76. Another Important Rule

Don’t disable TLS verification just because something isn’t working.

For example, avoid treating:

curl -k https://example.com

as a real fix.

-k tells curl to skip certificate verification.

It can be useful for controlled diagnostics, but it should not be used to hide a real certificate problem.

77. TLS Troubleshooting

If HTTPS fails:

1. DNS correct?
2. TCP 443 reachable?
3. Nginx listening?
4. Correct server_name?
5. Correct certificate?
6. Certificate not expired?
7. Correct private key?
8. Correct chain?
9. TLS configuration valid?
10. Nginx reload successful?

78. Useful Commands

Check Nginx

sudo nginx -t

Check port 443

sudo ss -ltnp | grep ':443'

Check certificate/TLS

openssl s_client -connect example.com:443 -servername example.com

Check HTTPS

curl -Iv https://example.com

Check certificate files

sudo ls -la /etc/letsencrypt/live/

79. Certificate Renewal Architecture

Think:

Certificate
     │
     ▼
Expiration date
     │
     ▼
Renewal process
     │
     ▼
ACME challenge
     │
     ▼
New certificate
     │
     ▼
Nginx reload
     │
     ▼
HTTPS continues

A hosting service must monitor this lifecycle.

80. The Most Important Vocabulary

Memorize:

TLS
=
Transport Layer Security

HTTPS
=
HTTP over TLS

Certificate
=
signed identity/public-key information

Public key
=
shareable cryptographic key

Private key
=
secret cryptographic key

CA
=
Certificate Authority

SNI
=
Server Name Indication

SAN
=
Subject Alternative Name

ACME
=
protocol used for automated certificate issuance/renewal

Let's Encrypt
=
publicly trusted certificate authority providing automated certificates

81. The Three Security Questions

Whenever you think about HTTPS, remember:

Confidentiality

Can someone read the data?

Integrity

Can someone modify the data without detection?

Authentication

Am I communicating with the intended server/domain?

TLS addresses these through cryptographic protocols and certificate-based authentication.

82. One Complete Example

Suppose:

shop.cresignsys.com

points to:

your VPS

The user visits:

https://shop.cresignsys.com

The chain is:

DNS
 ↓
VPS public IP
 ↓
TCP 443
 ↓
TLS handshake
 ↓
certificate for shop.cresignsys.com
 ↓
secure session
 ↓
HTTP request
 ↓
Nginx server block
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Every layer has a separate responsibility.

83. What You Have Learned

Your complete understanding is now:

DOMAIN
   ↓
DNS
   ↓
IP
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
NGINX
   ↓
PHP-FPM
   ↓
WORDPRESS
   ↓
MYSQL
   ↓
INNODB
   ↓
BUFFER POOL
   ↓
DISK

This is the core architecture behind the type of WordPress hosting system you are building.

Lesson 049 Summary

The key idea:

TCP creates the transport connection; TLS secures it; HTTP carries the web request.

So:

TCP
 ↓
TLS
 ↓
HTTP

And HTTPS:

HTTPS
=
HTTP
+
TLS

For your hosting platform, SSL automation is:

Domain
 ↓
ACME validation
 ↓
Let's Encrypt
 ↓
Certificate
 ↓
Nginx
 ↓
443
 ↓
HTTPS

Next Lesson — 050

DNS Deep Internals — From Domain Name to Your VPS

We will go deeper into:

Domain
 ↓
Registrar
 ↓
Nameserver
 ↓
Root DNS
 ↓
TLD DNS
 ↓
Authoritative DNS
 ↓
A / AAAA
 ↓
CNAME
 ↓
MX
 ↓
TXT
 ↓
TTL
 ↓
DNS cache
 ↓
Your VPS

Then we will connect it directly to your domains such as:

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

and explain exactly why changing DNS does not immediately change what every user sees, how propagation really works, and how to diagnose DNS problems from the command line.

Comments

Leave a Reply

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

More posts