SLTS CA Certificate Authority  ·  Internal PKI

What is SLTS CA?

SLTS CA is the Certificate Authority component of Static Labs Trust Services (SLTS). It issues and manages the digital certificates used to secure communications and verify identity across all Static Labs infrastructure — from API-to-API calls between backend services to hardware-level attestation for Kubian devices.

SLTS CA is not trusted by public browsers or operating systems by design. Its certificates are valid only within the Static Labs ecosystem, which means external parties cannot spoof or intercept traffic using certificates from unrelated CAs.

Where SLTS CA certificates are used

Trust Hierarchy

SLTS CA uses a two-tier chain of trust. The root CA is kept offline and only ever signs subordinate issuing CAs — it is never exposed to network traffic. Day-to-day certificate issuance is handled by the intermediates below it.

SLTS CA Root E1

The root CA. It uses ECDSA on the NIST P-256 curve (secp256r1), providing strong security with compact key sizes. The root is air-gapped — it signs intermediate CA certificates during provisioning events and is otherwise offline, so a compromise of any operational system cannot affect it.

SLTS CA Issuing G1

Issues short-lived TLS certificates for internal gRPC and REST services. Endpoints presenting an SLTS CA Issuing G1 certificate can be trusted as genuine Static Labs infrastructure.

SLTS CA Kubian G1

Dedicated to the Kubian attestation flow. After the server validates a device's hardware keystore certificate chain (including bootloader state, verified boot, and OS patch level), it issues a signed device certificate under this CA. Partner services verify that certificate to gate access without re-running the attestation themselves.

SLTS CA Root RSA-4096

A separate root key used exclusively for outbound network identity. When Static Labs services make outbound requests to partner or internal endpoints, the request is signed with this key and the signature is attached as an X-Net-Certificate-SLTS header. The receiving service fetches the public key from the CA endpoint and verifies the header to confirm the request genuinely originated from Static Labs infrastructure.

Upon receipt, the verifier should decode the Base64 value, verify the signature first, then check the exp field to confirm the certificate has not expired. Requests carrying an expired or unverifiable header must be rejected.

How Device Verification Works

When a device completes the Kubian attestation flow, the server issues a temporary device certificate — a short-lived, signed token valid for 15 minutes. Any internal service that receives this certificate can verify it independently without contacting the attestation server again.

The certificate is a base64-encoded JSON envelope with two fields: a payload containing the device claims, and a signature over that payload. Embedded inside the payload is an iss field containing the SLTS CA-signed issuer certificate generated at attestation time.

Verification steps

A verifying service performs four checks in sequence. All four must pass — failure at any step means the certificate is rejected.

1. Payload signature. The signature in the envelope is verified against the known SLTS CA server public key using ECDSA/SHA-256. This confirms the payload has not been tampered with since the attestation server produced it.
2. Expiry. The exp field in the payload is compared against the current UTC time. Certificates older than 15 minutes are rejected, limiting the window of exposure if a token is leaked.
3. Issuer certificate integrity. The embedded issuer certificate is parsed and checked: it must have the CA flag set, and its validity window must include the current time. This certificate was freshly generated by the attestation server at issuance time and is itself only valid for 10 minutes.
4. Key binding. The public key inside the issuer certificate is compared byte-for-byte against the expected SLTS CA server public key. This prevents an attacker from substituting a different, valid-looking CA certificate — the issuer must have been signed by the exact SLTS CA key, not just any CA.

On success, the verified payload exposes security_level (TEE or STRONGBOX), verified_boot, bootloader_locked, os_patch_level, and the device's own public key. Services use these fields to enforce their own access policies without repeating the attestation handshake.

Technical Specifications

SLTS CA root certificates are not distributed to public trust stores (Mozilla, Windows, Apple, etc.). They are strictly for verifying Static Labs infrastructure and authorized partner integrations. Verifying services should check the revocation list to reject certificates whose issuing keys have been retired or compromised.