dyzulk/trustlab-docs
1
0
Fork 0
mirror of https://github.com/dyzulk/trustlab-docs.git synced 2026-01-26 13:32:08 +07:00
Code Issues Packages Projects Releases Wiki Activity

refactor: migrate to official nextra i18n and native navigation

Browse Source
This commit is contained in:
dyzulk
2026-01-09 08:22:46 +07:00
parent 0817284eae
commit 9ce5d01315
54 changed files with 980 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
pages/guide/concepts/_meta.json
View File

@@ -1,4 +0,0 @@
{
"pki-undamentals": "PKI Fundamentals",
"trust-architecture": "Trust Architecture"
}

83
pages/guide/concepts/pki-undamentals.mdx
View File

@@ -1,83 +0,0 @@
import { Callout, Cards, Card } from 'nextra/components'
import { ShieldCheck, ShieldAlert, BadgeCheck, Lock, Key, Link, CheckCircle2, XCircle } from 'lucide-react'
# PKI Fundamentals & Trust Context
**Public Key Infrastructure (PKI)** is the framework that allows secure communication over the internet. It relies on cryptographic keys and a chain of trust to verify identities.
## Core Concepts
Understanding these two mechanisms is essential to understanding how TrustLab works.
### 1. Asymmetric Encryption
Secure communication relies on a pair of keys:
* <Key className="inline w-4 h-4 mr-1"/> **Public Key**: Shared with everyone. Used to **encrypt** data.
* <Lock className="inline w-4 h-4 mr-1"/> **Private Key**: Kept secret. Used to **decrypt** data and **sign** digital assets.
### 2. The Chain of Trust
A certificate is only trusted if it is signed by a known authority. This forms a chain:
* **Root CA**: The trusted anchor. It signs itself. You must install this on your device to trust the chain.
* **Intermediate CA**: Signed by the Root CA. Used to sign day-to-day certificates for security.
* **Leaf Certificate**: The final certificate used on your Web Server or Email.
---
## The Two Lanes of Trust
The internet security model is built on two distinct "lanes". Mixing them up causes browser errors, but using them correctly provides **Military-Grade Security**.
<Cards>
<Card icon={<ShieldCheck />} title="Public Lane (Global)" href="#public-pki" arrow />
<Card icon={<Lock />} title="Private Lane (Internal)" href="#private-pki-trustlab" arrow />
</Cards>
### Public PKI
* **Issuer**: Let's Encrypt, DigiCert, Google Trust Services.
* **Trust Model**: Pre-installed in every browser/OS (Chrome, Windows, iOS) by default.
* **Limitation**: **Cannot** issue certificates for Private IPs (`192.168.x.x`) or Internal Domains (`.local`, `.lan`).
### Private PKI (TrustLab)
* **Issuer**: TrustLab Root CA (Your Organization).
* **Trust Model**: Trusted **ONLY** by devices that have explicitly installed your Root CA.
* **Superpower**: Can secure **ANYTHING** internal (Localhost, Database Servers, IoT).
---
## Why "Military Grade"?
TrustLab utilizes **OpenSSL**, the same cryptographic core used by the world's highly secure networks.
| Feature | TrustLab (Private) | Public CA (Paid) |
| :--- | :--- | :--- |
| **Encryption** | RSA-2048 / RSA-4096 | RSA-2048 / RSA-4096 |
| **Signature** | SHA-256 | SHA-256 |
| **Protocol** | TLS 1.2 / 1.3 | TLS 1.2 / 1.3 |
| **Global Trust** | <XCircle className="inline w-4 h-4 text-red-500"/> (Manual Install) | <CheckCircle2 className="inline w-4 h-4 text-green-500"/> (Pre-installed) |
| **Internal IPs** | <CheckCircle2 className="inline w-4 h-4 text-green-500"/> Supported | <XCircle className="inline w-4 h-4 text-red-500"/> Forbidden |
| **Cost** | **Free** | $400+/month (Private CA) |
## Appropriate Use Cases
<Callout type="info" emoji={<BadgeCheck className="w-5 h-5" />}>
**The Golden Rule:**
Use **TrustLab** for anything the Public Internet CANNOT access.
Use **Public CAs** for anything the Public Internet MUST access.
</Callout>
### <CheckCircle2 className="inline w-5 h-5 text-green-500 mr-2"/> Perfect For (Green Lane)
* **Internal Tools**: Admin Panels, HR Portals, Dashboards.
* **Development**: Testing HTTPS on `localhost` or `dev.local`.
* **Databases**: Securing connections to MySQL/Postgres/Mongo.
* **S/MIME**: Encrypting email between internal employees.
### <XCircle className="inline w-5 h-5 text-red-500 mr-2"/> Do Not Use For (Red Lane)
* **Public E-Commerce**: Your customer's browser will show a "Not Secure" warning.
* **Public Blogs/Websites**: Random visitors do not have your Root CA installed.
## The "Trust Split" Myth
There is **no conflict** between having TrustLab installed and visiting public websites.
* When you visit `google.com`, your browser uses the **Public Lane**.
* When you visit `intranet.corp`, your browser sees the TrustLab signature and uses the **Private Lane**.
They coexist peacefully, providing comprehensive security for your entire digital life.

56
pages/guide/concepts/trust-architecture.mdx
View File

@@ -1,56 +0,0 @@
import { Callout, Steps } from 'nextra/components'
import { GitGraph, Shield, FileX, Network } from 'lucide-react'
# Trust Architecture
While the [Fundamentals](/guide/concepts/pki-undamentals) page explains *what* PKI is, this page explains *how* the hierarchy is structured to ensure security and scalability.
## The Hierarchy of Authority
TrustLab uses a standard **Three-Tier Architecture** (imulated in some modes) or a Two-Tier architecture to maximize security.
### 1. The Root CA (The Anchor)
* **Role**: The ultimate source of trust.
* **Behavior**: It signs **Intermediate CAs**. It almost **NEVER** signs end-user certificates directly.
* **Security**: If this key is stolen, the entire trust network is compromised. That is why in enterprise environments, the Root CA is often kept offline (air-gapped).
### 2. Intermediate CA (The Manager)
* **Role**: The working horse. It is trusted because the Root signed it.
* **Behavior**: It signs **Leaf Certificates** (for your servers).
* **Benefit**: If an Intermediate CA is compromised, you can revoke it using the Root CA without forcing every user to re-install the Root certificate.
### 3. Leaf Certificate (The Worker)
* **Role**: Validates a specific entity (e.g., `trustlab.local`, `api.internal`).
* **Behavior**: Cannot sign other certificates. It is valid only for a specific time (e.g., 397 days).
---
## The TLS Handshake (Simplified)
When you access `https://trustlab.local`, what actually happens?
<Steps>
### 1. Client Hello
Your browser sends a "Hello" to the server, listing supported encryption methods.
### 2. Server Hello & Certificate
The server responds with its **Leaf Certificate** AND the **Intermediate Certificate**. It does *not* send the Root.
### 3. Verification (The Chain Walk)
The browser looks at the Leaf. "Who signed you?" -> "Intermediate A".
The browser looks at Intermediate A. "Who signed you?" -> "Root CA".
The browser checks its **Local Trust Store**. "Do I have Root CA?"
* **Yes**: <span className="text-green-600 font-bold">Secure Connection Established</span>.
* **No**: <span className="text-red-500 font-bold">NET::ERR_CERT_AUTHORITY_INVALID</span>.
</Steps>
---
## Revocation (CRL & OCSP)
What happens if a private key is stolen *before* the certificate expires? Use Revocation.
* **CRL (Certificate Revocation List)**: A digital "Blacklist" file signed by the CA. Browsers download this list to check if a certificate is banned.
* **OCSP (Online Certificate Status Protocol)**: The browser asks the CA in real-time, "Is this specific serial number still good?".
TrustLab manages these mechanisms internally to ensure that if you delete a compromised certificate, it is effectively effectively untrusted (depending on client support for CRLs).