CresignSys Learn

CresignSys Learn — Lesson 040

Written by

cresignsys

in

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.

Comments

Leave a Reply

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

More posts