# Satellite PKI Trust & Revocation Policy
## Trust Hierarchy
```
CloudHSM Root CA (20-year, offline, FIPS 140-2 Level 3)
│ Stored: AWS CloudHSM backup in S3 (cluster-ew6yff4wjkx)
│ Access: Ceremony-only (2+ key custodians, air-gapped laptop)
│ NEVER woken for satellite ops — only for hub intermediate renewal
│
└─ Hub Intermediate CA (10-year, OpenBao, pathlen:2)
│ Stored: OpenBao on hub cluster (auto-unsealed via Shamir cronjob)
│ Scope: *.kuiperdesk.ai, *.arivaran.ai
│ Issuer: openbao-pki ClusterIssuer (cert-manager)
│ ISSUES satellite intermediates — no CloudHSM involvement
│
├─ Hub Service Certs (90-day, auto-renew)
│ aaHashSvc, aaTwinSvc, aaEnrollSvc, aaDash, Keycloak, etc.
│
└─ Satellite Intermediate CA (5-year or contract+3mo, pathlen:1)
│ ← ONE PER SATELLITE, issued by Hub Intermediate (NOT CloudHSM)
│ Stored: Satellite's step-ca (or OpenBao / K8s Secret)
│ Scope: Name-constrained to:
│ - *.satellite-<id>.kuiperdesk.ai (default subdomain)
│ - *.<custom-domain> (customer domain, if set)
│ Issued: During satellite bootstrap (hub-registration-job)
│ pathlen:1 allows step-ca to act as sub-CA for service certs
│
│ IMPORTANT: Name constraints are set HERE (per-satellite), NOT on
│ the root or hub intermediate. Root and hub intermediate have NO
│ name constraints — this allows satellites to issue certs for any
│ customer domain without re-issuing the root CA.
│
├─ Satellite Service Certs (90-day, auto-renew via step-ca)
│ Local aaHashSvc, aaTwinSvc, aaEnrollSvc, SeaweedFS, etc.
│
├─ Agent mTLS Certs (1-year, renewable via step-ca)
│ Endpoint agents enrolled to this satellite
│ TPM-bound private key (non-exportable)
│
├─ Keycloak Signing Keys (OIDC/SAML)
│ Tier A: own Keycloak instance on satellite
│
└─ Internal S3 TLS (90-day, auto-renew via step-ca)
SeaweedFS/CubeFS inter-node communication
```
### CloudHSM Wake Schedule
| Event | Frequency | What |
|-------|-----------|------|
| Hub Intermediate renewal | Every 10 years | Sign new hub intermediate CSR |
| Root CA renewal | Every 20 years | Generate new root (ceremony) |
| Satellite provisioning | **NEVER** | Hub Intermediate handles this |
| Satellite renewal | **NEVER** | Hub Intermediate handles this |
| Certificate revocation | **NEVER** | Hub OpenBao CRL/OCSP handles this |
## Name Constraints Strategy
```
CloudHSM Root CA → NO name constraints (trust anchor, max flexibility)
Hub Intermediate CA → NO name constraints (must issue for any tenant domain)
Satellite Intermediate CA → NAME-CONSTRAINED per tenant:
permitted: *.satellite-<id>.kuiperdesk.ai
permitted: *.<customer-domain> (if custom domain set)
```
**Why constraints only at satellite level:**
- Root/hub with `*.kuiperdesk.ai` constraint would block custom domains entirely
- Adding customer domains to root would require CloudHSM ceremony per customer
- Per-satellite constraints provide the same security (each satellite can only issue for its own domains) without limiting the root
- If a satellite is compromised, the name constraint limits what certs the attacker can forge
**Custom domain flow:**
1. Tenant sets `custom_domain: backup.megacorp.com` in dashboard
2. Hub issues satellite intermediate with `permitted_dns: [*.satellite-xxx.kuiperdesk.ai, *.megacorp.com]`
3. Satellite's step-ca can now issue certs for `api.backup.megacorp.com`, `backup.megacorp.com`, etc.
4. Agent's `ca-bundle.pem` contains root + hub intermediate + satellite intermediate → full chain
5. Browsers trust the chain after root is installed to trust stores (CATrust.cpp)
**If root was already issued WITH name constraints** (from the CloudHSM ceremony):
- Check: `openssl x509 -in root-ca.crt -text | grep -A5 "Name Constraints"`
- If constrained to `*.kuiperdesk.ai`: custom domains require a separate trust path
- Option: satellite generates its own self-signed root for custom domain → included in ca-bundle.pem
- Both roots in the bundle → agent/browser trusts both chains
- If no constraints: proceed as designed above
## Satellite CA Issuance (Bootstrap)
During satellite provisioning, the `hub-registration-job` in the Helm chart:
1. Generates an ECDSA P-384 keypair on the satellite
2. Creates a CSR with name constraints:
- Permitted DNS: `*.satellite-<uuid>.kuiperdesk.ai`, `*.<custom-domain>` (if set)
- pathlen: 0 (cannot issue further intermediates)
3. Sends CSR to hub's OpenBao PKI endpoint (authenticated via bootstrap JWT)
4. Hub OpenBao signs and returns the intermediate certificate
5. Satellite stores the signed cert + private key in its local OpenBao (or K8s Secret)
6. Satellite's cert-manager is configured with this intermediate as a ClusterIssuer
7. All satellite service certs are issued by this intermediate
```
POST https://api.kuiperdesk.arivaran.ai/v1/pki/satellite/sign-intermediate
Authorization: Bearer <bootstrap-jwt>
{
"csr": "<PEM-encoded CSR>",
"satellite_id": "uuid",
"custom_domain": "sat.customer.com", // optional
"ttl": "43800h" // 5 years
}
Response:
{
"certificate": "<PEM-encoded signed intermediate>",
"ca_chain": ["<hub-intermediate>", "<root-ca>"],
"serial_number": "hex",
"expiry": "2031-03-22T00:00:00Z"
}
```
## Revocation
### Mechanisms
| Method | Speed | Scope | Use Case |
|--------|-------|-------|----------|
| **CRL** (Certificate Revocation List) | Minutes (next CRL publish) | All relying parties that check CRL | Standard revocation |
| **OCSP** (Online Certificate Status Protocol) | Seconds (real-time query) | Per-certificate check | Immediate revocation |
| **Hub blocklist** | Instant | Hub services only | Emergency — hub rejects satellite traffic immediately |
| **satgw tunnel session drop** | Instant | Network layer | Satellite loses control-plane connectivity |
### Revocation Procedure
#### Standard Revocation (contract termination, non-renewal)
```bash
# 1. Revoke satellite intermediate in OpenBao
vault write pki_int/revoke serial_number=<satellite-cert-serial>
# 2. Publish updated CRL
vault write pki_int/crl/rotate
# 3. Remove satellite from hub registry
grpcurl hub:50052 TwinService/DeregisterSatellite -d '{"satellite_id":"uuid"}'
# 4. Drop the satellite's live satgw tunnel session (the revoked cert above
# blocks reconnection via OCSP/CRL). Terminate its active SatelliteConnect
# stream via the aaSatGwSvc admin interface for <satellite-id>.
# 5. Notify tenant (email + dashboard banner)
```
#### Emergency Revocation (security breach, hostile actor)
```bash
# 1. IMMEDIATE: Add to hub blocklist (takes effect in seconds)
kubectl exec -n kd-services aahashsvc-xxx -- \
curl -X POST http://localhost:9090/admin/blocklist \
-d '{"satellite_id":"uuid","reason":"security_breach"}'
# 2. Drop the satellite's live satgw tunnel session (cert revocation in step 3
# blocks reconnection) — terminate its active SatelliteConnect stream via
# the aaSatGwSvc admin interface (kills network in seconds)
# 3. Revoke certificate (standard CRL/OCSP flow)
vault write pki_int/revoke serial_number=<serial>
vault write pki_int/crl/rotate
# 4. Disable Keycloak realm/org (prevents any SSO)
curl -X PUT https://id.app.arivaran.ai/admin/realms/<realm> \
-H "Authorization: Bearer $KC_TOKEN" \
-d '{"enabled": false}'
# 5. Audit log entry (immutable)
# 6. Security team notification
```
### Revocation Scenarios
| Scenario | Action | Reversible? | Data Impact |
|----------|--------|-------------|-------------|
| **Contract termination** | Revoke CA + remove peer after 30-day grace | Yes (re-issue CA if renewed) | Data stays on customer hardware |
| **Non-payment** | Suspend first (stop cert renewal), revoke after 90 days | Yes (until revoked) | Data preserved |
| **Security breach** | Emergency revoke + blocklist + peer removal | Yes (new CA after remediation) | Forensic hold on hub metadata |
| **Compliance violation** | Suspend, investigate, revoke if confirmed | Depends on investigation | Audit trail preserved |
| **Hostile VAR** | Emergency revoke all sub-satellites | Per-satellite decision | Each satellite's data independent |
| **Tenant request** | Tenant self-service decommission in dashboard | Yes (within 30-day retention) | Data export available first |
| **Government order** | Legal team coordinates with counsel | Depends on jurisdiction | May require data preservation |
### Effects of Revocation
**What stops working:**
- Agent backups (mTLS certs rejected by satellite services)
- Agent command channel (gRPC connection fails TLS handshake)
- Dashboard file browsing (satellite API unreachable from hub)
- New agent enrollments (aaEnrollSvc certs invalid)
- Hub ↔ satellite metadata sync (overlay disconnected)
- All satellite service-to-service communication (certs issued by revoked CA)
**What continues working:**
- Data at rest on satellite hardware (encrypted, key in local OpenBao/TPM)
- Existing backups in satellite S3 (files on disk, not deleted)
- Hub's copy of tenant metadata (endpoints, snapshots, audit log)
- Other satellites for the same tenant (each has independent CA)
**What we explicitly do NOT do:**
- Delete customer data (their hardware, their data)
- Brick the machine (only KuiperDesk services stop)
- Expose the revocation reason publicly (only in audit log)
- Revoke without documented justification (audit trail required)
## Certificate Monitoring
Hub monitors all satellite intermediate CAs:
| Check | Frequency | Action on Failure |
|-------|-----------|-------------------|
| Expiry < 90 days | Daily | Alert tenant + auto-renew if connected |
| Expiry < 30 days | Daily | Critical alert + escalate to account team |
| OCSP responder reachable | Hourly | Alert SRE |
| CRL freshness < 24h | Hourly | Rotate CRL |
| Satellite heartbeat | Every 5 min | Dashboard status "disconnected" after 15 min |
## Compliance Mapping
| Framework | Control | How Satellite PKI Satisfies |
|-----------|---------|---------------------------|
| **SOC 2** CC6.1 | Logical access | Each satellite has unique CA — compromise of one doesn't affect others |
| **SOC 2** CC6.7 | Restrict data movement | Name constraints prevent satellite CA from issuing certs for other domains |
| **FedRAMP** IA-5 | Authenticator management | TPM-bound agent keys, auto-rotating service certs, CA hierarchy |
| **FedRAMP** SC-12 | Cryptographic key establishment | FIPS 140-2 Level 3 root (CloudHSM), standard key ceremonies |
| **FedRAMP** SC-17 | PKI certificates | pathlen constraints, name constraints, CRL/OCSP, 90-day auto-rotation |
| **FedRAMP** IR-4 | Incident handling | Emergency revocation procedure with < 60 second network isolation |
| **HIPAA** §164.312(d) | Person/entity authentication | mTLS with TPM-anchored identity per device |
| **ISO 27001** A.8.24 | Cryptography use | Full CA hierarchy documented, key lifecycle managed |
## Revision History
| Date | Change | Author |
|------|--------|--------|
| 2026-03-22 | Initial policy — satellite PKI trust chain, revocation procedures, compliance mapping | Claire Dubois (Security Architect), Navid Ahmadi (Compliance) |