me0nline/LOGAR
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 10 Wiki Activity

docs: update root README with Master License Authority, mTLS auto-renewal, and WebUI dashboard

Browse Source
This commit is contained in:
me0nline
2026-09-24 16:48:54 +02:00
parent d192b43aaf
commit 14533e0427
1 changed files with 33 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+33 -24
View File
@@ -88,40 +88,49 @@ graph TB
---
## mTLS Security, Dynamic PKI & Licensing
## mTLS Security, Dynamic PKI & Fleet Licensing
### 1. TLS 1.3 Mutual Authentication (mTLS)
- **Port 9443**: Ingestion occurs exclusively over TLS 1.3 sockets with `ssl.CERT_REQUIRED`.
- Both the hub and edge clients verify each other's certificates:
- Client verifies server certificate against `ca.crt`.
- Server verifies client certificate against the Root CA.
- **Client CN Identification**: In the TLS handshake, the server extracts the `commonName` attribute (`client_id`), validates that the client is marked `active` in the `clients` table, updates the `last_seen` timestamp, and drops unregistered or revoked certificates immediately.
- Server verifies client certificate against the Subordinate/Root CA.
- **Client CN Identification & Revocation**: In the TLS handshake, the server extracts the `commonName` attribute (`client_id`), validates that the client is marked `active` in the `clients` table, updates the `last_seen` timestamp, and drops unregistered or revoked certificates immediately.
### 2. Dynamic PKI Hub Engine (`src/server_enrollment.py`)
- **Root CA**: On first run, `Server.py` creates a self-signed Root CA (`ca.crt` / `ca.key`) valid for 10 years.
- **Server TLS Certificate**: Generated automatically with Subject Alternative Names (SANs) for `localhost`, `127.0.0.1`, server IP, and hostnames.
- **Authority Key Identifiers**: Full compliance with OpenSSL 3.x and Python 3.12–3.14 via `SubjectKeyIdentifier` and `AuthorityKeyIdentifier` extensions.
- **Dynamic Client Certificates**: RSA-2048 keys and X.509 client certificates are issued on the fly via the enrollment API.
### 2. Master License Authority (`logar.eibl.tech`) & Seat-Bearing Subordinate CA
- **Master Root Authority**: Standalone PKI service ([`src/License_Authority.py`](file:///u:/max/Desktop/LOGAR/src/License_Authority.py)) maintained at `logar.eibl.tech`.
- **Custom Enterprise X.509 OIDs**:
- `OID_LOGAR_SEATS (1.3.6.1.4.1.59999.1.1)`: Embeds the exact licensed seat quota directly inside the signed Subordinate CA certificate.
- `OID_LOGAR_LICENSE_ID (1.3.6.1.4.1.59999.1.2)`: Uniquely tracks enterprise license entitlement.
- `OID_LOGAR_ISSUER_URL (1.3.6.1.4.1.59999.1.3)`: Embedded endpoint coordinate (`https://logar.eibl.tech`).
- **Exportable `.lic` Request Files**:
- The LOGAR server generates its Subordinate CA private key (`certs/ca.key`), Certificate Signing Request (`certs/ca.csr`), and packages them into an exportable `logar_server.lic` file containing the CSR, server fingerprint, and license authority coordinate.
- Exportable directly from the WebUI or via CLI (`python src/Server.py --export-lic server.lic`).
- **One-Time Pass & Zero-Touch mTLS Renewals**:
- The signed CA certificate only needs to be imported **once** into the LOGAR Server (via WebUI or CLI `--import-ca`).
- Once imported, the server hub's background watchdog monitors `ca.crt` expiration (< 30 days).
- Renewals are performed **automatically over mTLS**: the LOGAR Server authenticates directly against `https://logar.eibl.tech/api/license/renew` using its existing active certificate and key, receives the renewed Subordinate CA certificate preserving its seat quota, and reloads its in-flight `ssl.SSLContext` without dropping client connections or restarting services.
### 3. Seat Accounting & Licensing
- Stored in SQLite table `license_config`:
- `max_seats`: Maximum concurrent active client licenses (default: 10).
- `enrollment_secret`: Cryptographic secret required for initial client enrollment.
- Stored in SQLite table `clients`:
- `client_id`: Unique client identifier (machine GUID or hardware hash).
- `hostname`, `os_type`, `cert_fingerprint`, `status` (`active` / `revoked`), `first_seen`, `last_seen`.
- When a new client enrolls:
- If `active_seats >= max_seats`, the hub rejects registration with `HTTP 403 (License seat limit reached)`.
- Existing registered clients can re-enroll / renew seamlessly without consuming additional seats.
### 3. Integrated Fleet Licensing & WebUI Dashboard
- **WebUI URL**: Accessible at `http://<server_host>:8443/webui` (or `/`).
- **Visual Seat Quota Meter**: Real-time progress bar displaying active forwarders vs. allocated seat limit.
- **Licensing Actions**:
- 1-click **Export .lic Request** file download.
- Interactive **View & Copy CA CSR** modal.
- Drag-and-drop or paste **Import Signed CA Certificate** modal.
- **Renew via mTLS Now** button for immediate upstream renewal.
- **Seat Management & Revocation Table**:
- Lists all connected Windows and Linux edge forwarders.
- **Revoke Seat**: Instantly drops and blocks the client at the TLS socket handshake layer.
- **Reactivate Seat**: Restores the client to active status if within seat quota limits.
### 4. In-Flight Certificate Watchdog & Automated Self-Healing Renewal
### 4. Cloud-Side In-Flight Certificate Watchdog
- **Continuous Hub PKI Watchdog**:
- The server hub runs a continuous background watchdog coroutine (`cert_validity_watchdog`, running every 12 hours) alongside startup checks.
- The hub automatically inspects expiration dates of both the Root CA (`ca.crt`) and the Server TLS certificate (`server.crt`).
- If either certificate is within 30 days of expiration, the server regenerates certificates (backing up previous keys as `ca.crt.<timestamp>.bak`) and dynamically reloads its active `ssl.SSLContext` in memory without dropping socket connections or restarting the service.
- The server hub runs a continuous background watchdog coroutine (`cert_validity_watchdog`, running every 12 hours).
- Automatically renews Subordinate CA certificates over mTLS with `logar.eibl.tech` and Server TLS certificates in-flight, dynamically reloading the active `ssl.SSLContext`.
- **Client Proactive Check & Reactive Self-Healing**:
- **Proactive Renewal**: Edge clients inspect `client.crt` before every run cycle. If the certificate expires in less than 30 days, it automatically contacts `/api/client/enroll` to renew its certificate.
- **Reactive Self-Healing**: If the server hub Root CA rotates or a handshake fails with `ssl.SSLError` / `SSLCertVerificationError`, edge clients catch the verification exception, re-bootstrap certificate enrollment against the hub, and re-establish the connection cleanly without human intervention.
- **Proactive Renewal**: Edge clients inspect `client.crt` before every run cycle. If expiring within 30 days, they contact `/api/client/enroll` to renew.
- **Reactive Self-Healing**: If the server CA rotates or a handshake error occurs, edge clients catch the exception, re-bootstrap enrollment against the hub, and re-establish streaming cleanly.
---