refactor: migrate to flat-file i18n structure and fix relative imports

pages/guide/concepts/_meta.id.json

@@ -0,0 +1,4 @@
+{
+    "pki-fundamentals": "Dasar-Dasar PKI",
+    "trust-architecture": "Arsitektur Kepercayaan"
+}

pages/guide/concepts/_meta.json

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

pages/guide/concepts/pki-fundamentals.id.mdx

@@ -0,0 +1,58 @@
+import { Steps } from 'nextra/components'
+import { Shield, Key, Lock, Globe } from 'lucide-react'
+
+# Dasar-Dasar PKI
+
+Memahami cara kerja **Public Key Infrastructure (PKI)** sangat penting untuk mengelola keamanan jaringan internal Anda. TrustLab menyederhanakan konsep kompleks ini menjadi alur kerja yang mudah dikelola.
+
+## Apa itu PKI?
+
+PKI adalah kerangka kerja yang terdiri dari peran, kebijakan, perangkat lunak, dan perangkat keras yang digunakan untuk membuat, mengelola, mendistribusikan, menggunakan, menyimpan, dan mencabut sertifikat digital.
+
+---
+
+## Komponen Utama TrustLab
+
+TrustLab mengelola tiga pilar utama keamanan untuk Anda:
+
+### 1. Root Certificate Authority (CA)
+Akar dari kepercayaan di seluruh jaringan Anda. Root CA digunakan untuk menandatangani sertifikat lain di bawahnya. Jika perangkat mempercayai Root CA ini, mereka akan mempercayai semua sertifikat yang diterbitkannya.
+
+### 2. Intermediate CA
+Digunakan oleh TrustLab untuk operasional sehari-hari. Kami tidak menggunakan Root CA langsung untuk menandatangani sertifikat pengguna akhir (end-entity) demi alasan keamanan (isolasi).
+
+### 3. Sertifikat Pengguna Akhir
+Sertifikat SSL/TLS yang Anda pasang di server web, perangkat IoT, atau klien email. Inilah yang sebenarnya "mengamankan" koneksi Anda.
+
+---
+
+## Cara Kerja Kepercayaan (Trust)
+
+Bagaimana browser Anda tahu bahwa sebuah situs web itu aman?
+
+<Steps>
+### Instalasi Akar
+Administrator menginstal Root CA TrustLab ke sistem trust store Anda.
+
+### Pengenalan Sertifikat
+Saat Anda mengakses situs internal, server menyajikan sertifikatnya.
+
+### Verifikasi Rantai
+Browser memeriksa: "Apakah sertifikat ini ditandatangani oleh pemegang yang saya percayai (Root CA)?"
+
+### Koneksi Aman
+Jika rantai valid, gembok hijau muncul dan enkripsi data dimulai.
+</Steps>
+
+---
+
+## Mengapa PKI Privat?
+
+Mungkin Anda bertanya, kenapa tidak menggunakan CA publik seperti Let's Encrypt?
+
+1.  **Domain Non-Publik**: CA publik tidak bisa mengeluarkan sertifikat untuk `.local` atau `.internal`.
+2.  **Kontrol Penuh**: Anda menentukan masa berlaku, algoritma enkripsi, dan siapa yang berhak mendapatkan sertifikat.
+3.  **Tanpa Validasi DNS**: Karena ini internal, Anda tidak perlu membuktikan kepemilikan domain ke pihak luar.
+
+> [!IMPORTANT]
+> Keamanan PKI privat Anda bergantung sepenuhnya pada **kerahasiaan Private Key Root CA**. TrustLab menyimpan key ini dengan enkripsi kuat untuk memastikan integritas jaringan Anda.

pages/guide/concepts/pki-undamentals.mdx

@@ -0,0 +1,83 @@
+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.

pages/guide/concepts/trust-architecture.id.mdx

@@ -0,0 +1,50 @@
+import { Steps } from 'nextra/components'
+import { Shield, Lock, Server, Users } from 'lucide-react'
+
+# Arsitektur Kepercayaan
+
+Arsitektur TrustLab dibangun di atas prinsip isolasi dan keamanan berlapis. Kami menggunakan struktur otoritas bertingkat untuk memastikan integritas jaringan Anda tetap terjaga.
+
+## Hirarki Otoritas Sertifikat
+
+Untuk keamanan maksimal, TrustLab tidak menggunakan satu kunci untuk semua hal. Kami menggunakan hirarki berikut:
+
+### 1. Root CA (Offline Root)
+Ini adalah "Ayah" dari segala kepercayaan. Key ini sangat sensitif dan idealnya jarang digunakan. Dalam infrastruktur yang sangat ketat, Root CA biasanya tetap offline.
+
+### 2. Intermediate CA (Issuing CA)
+TrustLab secara otomatis membuat Intermediate CA yang menandatangani sertifikat pengguna Anda. Jika Intermediate CA disusupi, Root CA dapat mencabutnya tanpa merusak seluruh ekosistem keamanan Anda.
+
+### 3. End-Entity Certificates
+Aplikasi atau server Anda menggunakan sertifikat ini. Mereka memiliki masa berlaku yang lebih pendek (biasanya 1 tahun atau kurang) untuk meminimalkan risiko.
+
+---
+
+## Alur Penerbitan Sertifikat
+
+Bagaimana data Anda berpindah dari dashboard hingga menjadi sertifikat sah?
+
+<Steps>
+### Permintaan Klien (CSR)
+Dashboard membuat sepasang kunci (Public & Private). Public key dikirim dalam format Certificate Signing Request (CSR).
+
+### Validasi Internal
+Dashboard TrustLab memverifikasi identitas Anda dan hak akses Anda terhadap domain yang diminta.
+
+### Penandatanganan CA
+Intermediate CA menandatangani CSR tersebut menggunakan Private Key CA-nya sendiri.
+
+### Pengiriman Sertifikat
+Sertifikat hasil tanda tangan dikembalikan ke Dashboard untuk Anda unduh.
+</Steps>
+
+---
+
+## Keamanan Kunci (Key Security)
+
+- **Enkripsi saat Istirahat (Encryption at Rest)**: Semua Private Key disimpan dalam database menggunakan enkripsi tingkat tinggi (AES-256).
+- **Isolasi Database**: Hanya layanan CA internal yang memiliki akses ke modul yang mendekripsi key tersebut.
+- **Audit Logs**: Setiap aksi penandatanganan dicatat dalam log sistem yang tidak dapat diubah (immutable logs).
+
+> [!TIP]
+> Jangan pernah membagikan file Private Key (`.key`) Anda kepada siapapun. Siapapun yang memiliki key tersebut bisa menyamar sebagai server Anda.

pages/guide/concepts/trust-architecture.mdx

@@ -0,0 +1,56 @@
+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).