Atom Certs need some love

[dborovcanin]

Atom certs are currently basic. We will need to improve on features to make them more useful in a real world for both devices and user, but also services and 3rd party entities. @SammyOina can add more details in the comment of this issue.

[SammyOina]

1. Current State vs. Target State

Feature	Current State (src/certs/)	Target State (Production PKI)
Enrollment Protocols	Direct GraphQL / gRPC API calls only	Standard protocols: EST (RFC 7030), ACME (RFC 8555), SCEP (RFC 8894)
CA Hierarchy	Static single Root or single Intermediate loaded from local files	Per-tenant Subordinate CAs, Multi-tier CA hierarchies, Pluggable HSM/KMS backends
Certificate Profiles	Hardcoded key usage (DigitalSignature, KeyEncipherment) & EKUs (ServerAuth, ClientAuth)	Dynamic Certificate Profiles/Templates with custom policies, validity caps, and extension rules
SAN & Extensions	DNS names and IP addresses only	SPIFFE URIs (spiffe://...), Email SANs, UPN, Hardware Serial, Custom OIDs
Device Attestation	Trust based solely on API credential auth	TPM 2.0 / Hardware EK verification, EST Initial Trust / One-time enrollment tokens
User Onboarding	Raw PEM output	JWT-to-Cert Exchange & PKCS#12 (.pfx) export with passphrase encryption
OCSP Performance	On-the-fly signing for every OCSP request	Pre-computed & cached OCSP responses (Postgres / Redis) with stapling support
Lifecycle & Alerting	Manual querying for expired certs	Event-driven Webhooks, Prometheus metrics, and automated expiry alerts (cert.expiring_soon)

2. Pillar 1: Automated Enrollment Protocols (Devices & Gateways)

IoT edge nodes (e.g., Magistrala gateways) and constrained devices cannot easily run custom GraphQL/gRPC clients for certificate provisioning.

2.1 EST (Enrollment over Secure Transport - RFC 7030)

Add native Axum routes under /certs/est/.well-known/est/:

• GET /cacerts: Return the current CA certificate chain in PKCS#7 / PEM format.
• POST /simpleenroll: Accept PKCS#10 CSR with HTTP Basic Auth (entity credentials) or mTLS (bootstrap cert).
• POST /simplereenroll: Renew existing cert using mTLS authentication with the current active certificate.
• POST /serverkeygen: Optional server-side key pair generation for ultra-constrained devices.

2.2 ACME Protocol Support (RFC 8555)

• Provide lightweight ACME v2 endpoint (/acme/directory, /acme/new-nonce, /acme/new-order, /acme/revoke-cert).
• Enable seamless integration with standard tools like cert-manager in Kubernetes or traefik/caddy.

---

3. Pillar 2: Certificate Profiles & Policy Engine

Replace hardcoded certificate parameters in src/certs/service.rs with configurable Certificate Profiles.

3.1 Profile Schema (cert_profiles Table)

CREATE TABLE cert_profiles (
    id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id     UUID REFERENCES tenants(id) ON DELETE CASCADE,
    name          TEXT NOT NULL, -- e.g. "iot-device-leaf", "spiffe-workload", "user-mtls"
    max_ttl_secs  BIGINT NOT NULL,
    key_types     TEXT[] NOT NULL DEFAULT '{"ECDSA_P256", "RSA2048"}',
    key_usages    TEXT[] NOT NULL,
    ext_key_usages TEXT[] NOT NULL,
    allowed_sans  JSONB NOT NULL DEFAULT '{}', -- regex patterns for DNS/IP/URI/Email
    custom_oids   JSONB NOT NULL DEFAULT '{}',
    is_ca         BOOLEAN NOT NULL DEFAULT FALSE,
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

3.2 Key Capabilities

• SPIFFE / SPIRE Support: Support URI SANs matching spiffe://<trust-domain>/ns/<tenant>/sa/<entity_name> for zero-trust microservice identities.
• Hardware & Device Extensions: OIDs for hardware serial numbers, MAC addresses, or custom vendor attestation attributes.
• Enforcement at Issuance: Validate incoming CSRs against the assigned profile before signing.

---

4. Pillar 3: Multi-Tenancy & Pluggable CA Backends

4.1 Per-Tenant Subordinate CAs

• Extend Atom's multi-tenant architecture so each tenant can have its own Intermediate Certificate Authority (ICA).
• Isolate tenant certificates so Tenant A's CA cannot issue valid certificates for Tenant B's entities.

4.2 Pluggable CA Signing Backends (CertificateIssuer abstraction)

Abstract key storage and signing operations behind a Rust trait:

#[async_trait::async_trait]
pub trait CaBackend: Send + Sync {
    async fn sign_csr(&self, csr_der: &[u8], params: &SigningParams) -> Result<Vec<u8>, AppError>;
    async fn get_ca_chain(&self) -> Result<Vec<u8>, AppError>;
}

Implementations:

1. Software / Disk CA (current rcgen file-based implementation).
2. HashiCorp Vault PKI (delegating signing to external Vault clusters).
3. AWS Private CA / Cloud KMS (hardware-backed private keys).
4. PKCS#11 / Hardware Security Modules (HSM) (e.g. YubiHSM, AWS CloudHSM).

---

5. Pillar 4: User & Service Identity Features

5.1 Token-to-Certificate Exchange (OIDC/JWT $\rightarrow$ X.509)

Allow users or services authenticated via JWT/Bearer token to perform a self-service certificate exchange:

• POST /certs/exchange: Authenticated endpoint that generates a short-lived mTLS client certificate tied to the authenticated AuthContext.
• Encodes user identity attributes (e.g., email from entity_emails, name, tenant_id) into Subject DN and Email/URI SANs.

5.2 Browser-Friendly PKCS#12 / PFX Bundles

• Add an export option on issueCertificate to return a password-protected .pfx / .p12 file (containing leaf cert + private key + CA chain) for direct installation in OS trust stores or web browsers.

---

6. Pillar 5: High-Performance Revocation & Observability

6.1 Pre-Computed / Cached OCSP Responders

• Shift OCSP status generation from on-the-fly signing to asynchronous pre-computation.
• Store signed OCSP responses in PostgreSQL / Redis cache with background refresh to support thousands of OCSP requests/sec from IoT device fleets.

6.2 Expiration Monitoring & Event Webhooks

• Background Cron / Task: Periodic scanner detecting certificates nearing expiration (e.g., 30d, 7d, 24h).
• Webhooks & Audit Events: Fire compliance audit events (cert.expiring_soon, cert.issued, cert.revoked) to notify external monitoring systems (PagerDuty, Slack, NATS/MQTT).
• Prometheus Metrics:
  • atom_certs_active_total{tenant_id, profile}
  • atom_certs_expiring_soon_total{days_remaining}
  • atom_certs_revoked_total
  • atom_est_requests_total{endpoint, status}